...and aggregated calendars:
- http://www.icann.org/general/calendar/
- http://www.isoc.org/isoc/conferences/events/
I've been maintaining an integrated calendar across our related
meetings for awhile now. For folks using iCal or compatible tools,
you can subscribe via the webcal link
On Jan 16, 2008, at 1:37 PM, Mike Donahue wrote:
Anyway, it's all getting (for us) pretty complicated. We're a fairly
small firm and just want an Ethernet handoff with our IP block on it.
Sprint didn't blink at the request, but ATT... We're getting a good
rate from ATT for the IP services
On Dec 26, 2007, at 8:26 AM, Leo Bicknell wrote:
In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500,
Kevin Loch wrote:
RA is a shotgun. All hosts on a segment get the same gateway. I
have
no idea what a host on multiple segments with different gateways
would
do. Hosting
On Jul 23, 2007, at 12:48 PM, Xin Liu wrote:
I have a question about unrecognized BGP path attribute. According to
RFC4271, when a BGP router sees an UPDATE with an unrecognized
optional and transitive path attribute, it should retain the
attribute, and if the path is selected, it should
It was possible to implement BCP38 before the router vendors
came up with uRPF.
Further, uRPF is frequently a very inefficient means of implementing BCP
38. Consider that you're going to either compare the source address
against a table of 200,000 routes or against a handful of prefixes
Pekka Savola wrote:
On Thu, 26 Oct 2006, Tony Li wrote:
It was possible to implement BCP38 before the router vendors
came up with uRPF.
Further, uRPF is frequently a very inefficient means of implementing BCP
38. Consider that you're going to either compare the source address
against
Hi Vadim!
Vadim Antonov wrote:
On Thu, 26 Oct 2006, Tony Li wrote:
Further, uRPF is frequently a very inefficient means of implementing BCP
38. Consider that you're going to either compare the source address
against a table of 200,000 routes...
That would be, well, about 6 memory
Nah. You assume branching factor of 2 (and not radix tree but
rather a
form of binary tree, i.e. AVL, r/b or Patricia - they have that
O(log2(num_entries)) behaviour, while radix trees are traversed in
O(key_length/branching_factor)).
I assumed a binary radix trie (not tree) because
8 years ago today was the beginning of the end.
No, it was the end of the beginning.
Tony
What you see in BGP is not necessarily what you get for
actual routing.
This isn't the only situation where advertisements do not
match actual
routing. Consider traffic engineering systems such as the
Internap FCP (old
NetVMG). Imagine I have two upstreams (A and B) and you
3)
What's wrong with treating assignments like property and setting up a market
to buy and sell them? There's plenty of precedent for this:
Mineral
rights, mining claims, Oil and gas leases, radio spectrum.
If a given
commodity is truly scarce, nothing works as good as
Has anyone ever managed to open a dialogue with symantec
(or comcast)
about that fscked up proprietary RBL they are using?
We're on the verge of just giving up on comcast
I know Sender Verification Callback has its issues, but maybe it
would make sense to only accept email from
I also suspsect that the community is not ready to transition to
liquid-cooled systems.
I rather assumed 'at room temperature' implied a standard heat sink
and fan.
Perhaps there's not enough information in that article to draw a
conclusion from.
There are a few bits that folks
IBM and Georgia Institute of Technology are experimenting
with silicon-
germanium, it is said here:
http://tinyurl.com/g26bu
I find this interesting having just attended NANOG 37 where some
manufacturers of network devices told us in a panel that network
heat problems weren't
Stephen Sprunk wrote:
Who exactly has been trying to find scalable routing solutions?
Well, for the last decade or so, there's been a small group of us who
have been working towards a new routing architecture. Primary
influences in my mind are Chiappa, O'Dell, Hain, Hinden, Nordmark,
The alternative, of course, is to wait for IDR to implode and let the
finger-pointing begin.
... which is what I expect to happen. A few folks will see it coming,
design a fix, and everyone will deploy it overnight when they discover
they have no other choice. Isn't that about what
Marshall,
That's after 6 years.
I would be surprised if Shim6 going into actual deployed boxes was any
faster. So, if Shim6 was finalized today, which it won't be, in 2010 we
might have 70% deployment and in 2012 we might have 90% deployment.
I actually think that 2012 would be a more
Also, from a research standpoint I'm curious as to why this
organization thinks they need ARIN IP space to do what they do.
Most of us know that's probably not true. I keep pretty close tabs
on ongoing research in network location based services, dns
mapping, online advertising,
Routing slots aren't the only resource you're consuming. In
general, many of the prefixes coming out of a given AS have common
attributes, e.g. path, MEDs, etc. Those attributes are stored only
once (at least in the BGP implementation I know) even if they're
used by hundreds of
The telephone companies are asking for the same ability to sell
multiple
services over the same physical line. Cable companies didn't make
their
Internet service slower when they add more private services, why do
people expect the telephone companies to make their Internet service
worse
I guess you missed all those trenches being dug in Verizon land to
install
fiber to the home. I guess you missed all the network upgrades in
ATT/SBC
and Bellsouth land to shorten their copper loop distances.
Sounds like they are manufacturing more bandwidth and the zero sum
game
is
What good is 6Mbit DSL from my ISP (say, SBC for example) if only a
small
portion of the net (sites that pay for non-degraded access) loads at a
reasonable speed and everything else sucks?
One might argue that in such a situation, the end user is getting
less value than they
did
An alternative for sbgp design could be that aggregating ASN would
create special self-signing cert for such aggregate block and that
cert would have special attribute(s) indicating list of all sub-
blocks and reference
to all certs that make this aggregate block. Then verifying router
On Nov 13, 2005, at 9:09 AM, Scott Bradner wrote:
bridge where you can, route where you must. -- i forgot
where this
came
from? Radia?
Cabletron
And before that, Vitalink.
;-)
Tony
Do we *really* want to do anything to encourage a higher burn rate
of AS numbers
before we've deployed 32-bit AS number support?
The only way to get 32-bit AS number support deployed is to run out
of AS numbers in
the 16 bit space.
Tony
I understand BGP flapping to be announcements followed by
withdraws over a short period. I am seeing a peer with a large
number of announcements and the normal number of withdraws. Is
there a term to describe what I am seeing? I'd like to understand
what is happening, but I've been
On Oct 23, 2005, at 11:33 PM, Alexei Roudnev wrote:
One question - which percent of routing table of any particular
router is
REALLY used, say, during 1 week?
I have a strong impression, that answer wil not be more than 20%
even in
biggerst backbones, and
will be (more likely) below
the internet model is to expect and route around failure.
You cannot stop the last mile backhoes.
Tony
PS: Btw, anyone can give me a hint on where to discuss new ideas for
e.g. routing schemes (and finding out whether it's an old idea)?
You might start with the routing-discussion mailing list:
http://www.rtg.ietf.org/
Please expect that your idea has been discussed before. We're an old
Daniel,
I think it is safe, even with projected AS and IP uptake, to assume
Moore's law can cope with this.
Moore will keep up reasonably with both the CPU needed to keep BGP
perking, and with memory requirements for the RIB, as well as other
non-data-path functions of routers.
True enough, but unfortunately, it's not done in a way that we can
make use of the identifier in the routing subsystem or in the
transport protocols.
The transport protocols, well they generally act on behalf of
something which can do the lookup and supply transport with right
Andre,
capacity = prefix * path * churnfactor / second
capacity = prefixes * packets / second
I think it is safe, even with projected AS and IP uptake, to assume
Moore's law can cope with this.
This one is much harder to cope with as the number of prefixes and
the link speeds are
David,
A real locator/identifier separation requires a rewrite.
Not necessarily. If you transition at the edge, what happens
within the site matters only to the site and what matters to the
core only matters to the core. No stacks, either core or edge,
need to be rewritten.
Daniel,
But wasn't that the rationale for originally putting the kitchen
sink into IPv6, rather than fixing the address length issue?
The stated rationale was to fix the address length issue.
I think we missed a lot of opportunities.
Amen.
We're 10 years on, and talking about
Paul,
This is completely orthogonal to a real identifier/locator split,
which would divide what we know of as the 'address' into two
separate spaces, one which says where the node is,
topologically, and one which says who the node is.
Hmm, no idea whether it's a good idea or not, but
Fred,
If we are able to reduce the routing table size by an order of
magnitude, I don't see that we have a requirement to fundamentally
change the routing technology to support it. We may *want* to (and
yes, I would like to, for various reasons), but that is a different
assertion.
Daniel,
If we're going to put the world thru the pain of change, it seems
that we should do our best to ensure that it never, ever has to
happen again.
That's the goal here? To ensure we'll never have another protocol
transition? I hope you realize what a flawed statement that is. We
Fred,
So the routing problem was looked at, and making a fundamental
routing change was rejected by both the operational community and
the routing folks.
No, IPv6 doesn't fix (or even change) the routing of the system,
and that problem will fester until it becomes important enough to
but when similar things were proposed
at other meetings, somebody always said no! we have to have end-
to-end,
and if we'd wanted nat-around-every-net we'd've stuck with IPv4.
Is VJ compression considered a violation of the end-to-end
principle?
Or perhaps I misunderstand (yet again).
Shifting the NAT to end system removed the objection to NAT, tho
it's not entirely clear why. Shifting NAT to the end system also
happened to simplify the entire solution as well.
Except for the part about having to rewrite all existing
implementations to take full advantage of the
Certainly does. Apparently this or a similar idea was suggested
back in
1997, and is the root origin of the 64 bits for host address space,
according to Christian Huitema, in his IPv6 book -
http://www.huitema.net/ipv6.asp.
A google search found the draft :
GSE - An Alternate Addressing
Doesn't NAT, or more specifically the most commonly used, NAPT, create
hard state within the network, which then makes it violate the
end-to-end argument ? Also, because it has to understand transport and
application layer protocols, to be able to translate embedded
addresses,
doesn't this
How is a split between locator / identifier any different logicaly
from the existing ipv4 source routing?
IPv4 source routing, as it exists today, is an extremely limited
mechanism for specifying waypoints along the path to the destination.
This is completely orthogonal to a real
Perhaps that middle ground is a mix of these 2 things?
Perhaps. But what we currently seem to believe is that current
routing table growth is dominated by traffic engineering and
multihoming. If future routing is to scale better than today, then
we need some strong forces that push
So the IETF identified 4 reasons to multihome. Of those 4, shim6
ignores at least 2 of them (operational policy and cost), and so
far as I can see glosses over load sharing.
If you have a solution that satisfies all requirements, you should
contribute it. Shim6 is indeed a partial
Daniel,
The alternative is a multihoming scheme that does not require a
prefix per site. But that doesn't match the stated requirement of
'conventional', 'proven', 'working' [sic], 'feature-complete'.
Those weren't the stated requirements on an alternative multihoming
scheme,, but only
I don't have an acceptable solution... however, I am getting tired
of shim6 being pushed as *the* solution to site rehoming, when at
best it's an end node rehoming solution.
Well, sorry. When we explored site multihoming (not rehoming) in the
ways that you seem to suggest, it was
But I think the discussion is mood. IETF decided on their goal, and
it's superfluous trying to change that. While watching shim6 we carry
on hoping that we'll get IPv6 multihoming going in the conventional,
proven, working, feature-complete way we're used to... until IETF
there is no hope in
in a pay-me-now-or-pay-me-later scenario, you have to pick now
vs. later.
(it's a pity that the internet, for all its power, cannot alter
that rule.)
It should be noted that if one opts for 'later', you can do quick and
dirty games with NAT. Do not renumber, change providers and put a
On Oct 7, 2005, at 11:54 AM, Paul Vixie wrote:
[EMAIL PROTECTED] (Daniel Golding) writes:
Take-away: Do not single home. I'm shocked folks aren't figuring
this out.
If you are a webhoster or enterprise and your business model can
not support
multiple Internet pipes, than you have a
In general I agree with you. The primary exception being that if
national
political interests want to press for local rules about specific
strings
(like XXX) then those national interests belong in their designated
part of
the name space. Polluting the global space with nationally
On Sep 29, 2005, at 2:08 PM, Randy Bush wrote:
Saudi Arabia, Iran, Northern Nigeria, and China are not likely to
have the same liberal views as, say, the Netherlands or Denmark.
Saudi Arabia and China, like some other nations, extensively filter
their Internet connection and have created
Actually, I think you've got it backwards. .us and all of the other
country-specific TLDs are the last vestiges of nationalism.
The problem is that all gTLD are controlled only in the US (even more
than the root is). So, they are international only in name.
Obviously, I feel that that
.com is an abomination, as are the other gTLDs to a lesser
extent. .gov,
.mil, .edu, .info, and .biz need to be shifted under .us
immediately, and
everyone under .com, .net, and .org needs to be gradually moved
under the
appropriate part of the real DNS tree. I can live with .int
That's not at all surprising. PBR would be pretty hard to push
into a hardware forwarding path.
Not impossible, but certainly challenging.
Doesn't the SUP-720(PFC3B) support (some forms of) PBR in hardware ?
As has been pointed out to me privately, the SUP-720 does flow cache
PBR
On Sep 17, 2005, at 8:57 PM, David Hubbard wrote:
Just curious, do most vendors' hardware need to hit the
cpu when doing policy-based routing? I found one of my
border routers' cpu's on the bad end of a DDoS but once
I turned off a not necessarily required setup to force
some outbound
Waitaminute - isn't the whole *purpose* of layer 3
that the network makes these routing decisions?
If there are N routers in an ISP, I would expect the
ISP to connect to X endsystems, where 10N X 1000N.
How does knowing about X endsystems scale better than
knowing about N
The rules today have not resulted in and overly huge number of
multihomers.
I suspect that is a matter of perspective. Even if 10% of all sites are
multihomed, and we continue in the IPv4 multihoming model, then we will
end up with slow exponential growth of the routing table which
Whilst this thread is open... perhaps someone can explain to me how
shim6 is as good as multihoming in the case of redundancy when one of
the links is down at the time of the initial request, so before any
shim-layer negotiation happens.
I must be missing something, but there's a good
Or, on top of that, how traffic engineering can be performed with shim6..
-igor
(firmly in the shim6 does not adress *most* of the issues camp)
Shim6 doesn't do what most end user sites would like to think of as
traffic engineering.
For a multihomed site, traffic engineering is about
i opine that some features are innovation and others not. i.e.,
x.25 support on modern kit seems a not innovative and a waste of
resources i would rather see applied elsewhere.
Probably a fairer characterization.
but every feature has its cost in complexity and resources to build
and
I'm sorry, but this is simply an unsupportable statement. What is
required of routers is that the provider be able to configure the device
to make copies of certain packets to a monitoring port. Assuming that
the monitoring port is duly managed, how does this qualify as insecure?
It
This isn't trivial to do, but it isn't rocket science either!
True, but you ARE suggesting that Cisco produce a binary patch, to a
possibly compressed image.
I think you should really think long and hard before you conclude that
you really want that. IMHO, the risk/reward ratio as compared
At the risk of continuing this bad flashback...
A Cisco CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR comes with
4 GB of route memory default size. Juniper's T320 and T640 come with
2 GB of main memory default size. That should take them to some higher
number of routes.
No, sorry,
And finally, we're doing it, we're not doing it, Surprise, we did it
is a crappy way to notify the community that they're about to piss in
the global pool. At least there was some level of notification, but why
bother if you're not going to stick to what you publicize?
One might suspect
Members aren't looking for Operator experience (sic). Members are
looking for talks that do not suck.
(sic) is a matter of interpretation, and, you already said the talks
suck. The PC said they don't get enough talks. Some of the talks are
going to be filler.
Put more constructively,
Todd,
- Forged AS paths and AS path segments
ditto, provided that you have long enough AS path segments in your
list of valid prefixes. if you have a long enough memory of routes
and a fast enough system, it's trivial to produce weighted lists of
the likelihood of a given prefix-path
Daniel, Todd,
The most significant problem is hijacking of IP address space for various
purposes. That's it. Solve that in the SIMPLEST way possible, lets implement
it (because everyone sees the problem) than we can either iteratively
improve the solution or start working on the next
Steve,
I know all the issues up there are real, since I've occasionally heard
about them happening. I understand the devastating consequences of
somebody finding a sufficiently well connected unfiltered BGP session
and using it to announce some important prefixes. I fully agree that it
Daniel,
Well, I wish I could have been part of the discussions that you had, as
what you report is at variance with what I've heard.
Fundamentally, there is a serious scalability issue with doing
everything at configuration generation time. Since one cannot predict
with certainty what AS
Randy,
wrong. as deployment will be expensive and long, we will have one chance to
deploy. so need a serious solution set for what we have to consider to be a
very serious attack model. plan for attacks against the routing system as
smart, well-researched, constant, ... as the best we
Pekka,
First of all, if you are assuming that NO ISPs make use of prefix
filters, then you would be incorrect. There are those that try very
hard to make use of such filters. However, we do not have 100%
deployment of those filters.
Since we will never see 100% deployment of such filters,
i receive a bgp announcement from a new peer, but the announcement
was originated two weeks ago (shockers! a stable route); was the
asserted path to my new peer valid when the announcement was
originated two weeks ago? once your mind starts down such paranoid
paths, the void opens before
-- You must not rely on routing to secure routing.
I would like to point out that this goal is unnecesary.
First, we need to understand that for ANY solution to be deployable, it
must be incrementally deployable. We do not get an Internet-wide flag
day for BGP. The Internet must continue
Daniel Senie wrote:
There are basically two issues: the forwarding table and BGP
processing. Information in the forwarding table needs to be found
*really* fast. Fortunately, it's possible to create datastructures
where this is possible, to all intends and purposes, regardless of the
size of
For those not familiar, BitTorrent is a file sharing app that is
commonly
used for exchanging full movies. As such, folks are moving gigabyte
files regularly and it's not surprising that this is detectable.
Shuffling .mp3's around would be trivial by comparison.
Tony
On Nov 5, 2004, at 6:34
I wanna know why Peter Packet doesn't have a Swedish accent!
;-)
Tony
I tried configuring my router this way but all I got were syntax
errors...
Can we PLEASE move on?
Thanks,
Tony
On Sep 25, 2004, at 2:10 PM, Alexei Roudnev wrote:
Hmm.
It was not developing countries, who claimed _free trade_; it was
_developed
counrties_. When free trade was coming, it
However, there is text in the RFC 2453 that states that RIP can use
this message to request specific networks also. It also states that
such a request can only be made by a diagonistic software and cannot
be used for routing. My doubt is, how can a diagnostic software, use
the services of RIP for
Did they arrest the crew? They have grounds on negligence
charges...
Tony
On Aug 23, 2004, at 3:12 PM, David Lesher wrote:
Speaking on Deep Background, the Press Secretary whispered:
Via:
http://www.hindustantimes.com/news/181_965656,00050002.htm
Sri Lanka court holds back Indian ship, seeks
On Aug 4, 2004, at 10:53 PM, Paul Jakma wrote:
On Wed, 4 Aug 2004, Alexei Roudnev wrote:
I am sorry, but I do not make a theory - I just repors practical
results. 2 CPU systems are much more stable than 1 CPU system, in my
experience. You are free to find an explanatiion, if you want -:).
The
You mean that they're not near any *known* fault lines. Remember
Northridge?
If you're in CA or NV, you *are* near a fault line, no matter where you
are.
http://quake.wr.usgs.gov/recenteqs/Maps/122-39.htm
http://quake.wr.usgs.gov/recenteqs/latest.htm
Tony
On Jul 16, 2004, at 3:53 PM,
On Jul 6, 2004, at 5:27 PM, Brad Gould wrote:
Does anyone know any useful contacts for .mil?
I have what looks to be filter issue with them, being some, but not
all,
of 203.122.192.0/18 not being able to access some sites (www.usmc.mil
for one). Its a reasonable new IP range allocation.
I've
On Jul 5, 2004, at 5:00 PM, Patrick W Gilmore wrote:
On Jul 5, 2004, at 2:02 PM, vijay gill wrote:
Throwing ethernet cables over the ceiling does not scale.
Sure it does. The question is: How far does it scale? Nothing
scales to infinity, and very, very few things do not scale past the
Is it really important to know the link speeds? What good does it do
without knowing
about the loading on those links?
I would MUCH rather have an empty T1 than have to contend with a very
oversubscribed OC-768.
Tony
On Jul 1, 2004, at 5:25 PM, Cody Lerum wrote:
DNS can sometimes give you a
Various people I've asked about this have said they wouldn't use the .0
or .255 addresses themselves, though couldn't present any concrete info
about why not; my experience above would seem to suggest a reason not
to
use them.
The .255 address is very likely to be a broadcast address from a
At the high end, you might want to look at Ixia.
Tony
On Jun 18, 2004, at 2:39 PM, Vicky wrote:
Hi there,
Just wondering what folks out there have used or are using (such as
smartbits, etc) for measuring the performance (benchmark) limits for
engineering and qa testing. I'm looking at doing
With the current facilities as they are, a simple calculation shows
that
actual communications traffic will exceed the backbone's maximum
capacity as
soon as five years from now.
Since when is this is a good indicator? If we ignore any of the growth
in facility capacity in the last 5 years,
Agreed. I am surprised that noone else have brought that up. I
understand that the software is built in a way that might not make
sense to port to all Cisco platforms, but it would be nice to have on
at least the GSRs.
I've heard the rumor that that would be the first port that they would
No. The BFR was the development name for Tony Li's last Cisco project
and morphed into the GSR. The processor card in at least early GSRs had
a BFR sticker on them.
Pardon, but I need to set the record straight here... It was not by
any stretch of the imagination 'my' project. There were dozens
Well, that's pretty impressive. Since you're not using Juniper or
Cisco, whose
gear are you using?
Tony
On May 25, 2004, at 12:58 PM, Matthew Kaufman wrote:
So you never run any production code that was compiled with gcc?
And, let me guess, your web servers all run IIS?
Matthew Kaufman
[EMAIL
No, that's compiled with gcc too. ;-)
Tony
On May 25, 2004, at 2:02 PM, Christian Malo wrote:
procket ? :)
-chris
On Tue, 25 May 2004, Tony Li wrote:
Well, that's pretty impressive. Since you're not using Juniper or
Cisco, whose
gear are you using?
Tony
On May 25, 2004, at 12:58 PM, Matthew
It needs to be set of trusted time sources that is as reliable as you
feel is necessary.
If you're feeling extremely paranoid, then you can use the -g flag to
peer with a number
of your private stratum 1 sources and then let the sanity checking do
its job to
avoid any bogochimers.
Tony
On
One minor (operational! -- gasp) addition:
More modern copies of ntpd have a '-g' option that will allow
the clock to jump once at boot time.
Tony
On May 20, 2004, at 12:27 PM, Randy Bush wrote:
sorry to take you away from discussing spam with an actual
tech note, but twice this morning i have
It certainly looks (approximately) genuine, with Kirk's normal coding
style and
normal calls to IOS infrastructure routines.
Tony
On May 15, 2004, at 1:21 PM, John Kinsella wrote:
For those not on bugtraq...I can't hit securitylab.ru, so would be
curious if anybody has more info or
What's very amusing is reading section 5 of the draft, wherein the
author
distributes credit to a number of parties. If Cisco were to file a
patent
at this point and not include those parties (including other companies),
the patent validity would be at risk by reason of excluding a
I am not sure that 254 is a good maximum number. Perhaps someone in the
know can enlighten all of us as to why they chose to stop at 254 instead of
255.
I can think of at least one vendor who decremented TTL prior to letting the
packet
come up to the RP. Further, the same vendor would drop
97 matches
Mail list logo
