Patrick W. Gilmore wrote:
On May 5, 2008, at 10:39 AM, Rich Kulawiec wrote:
On Mon, May 05, 2008 at 07:20:17AM -0700, Lynda wrote:
It is something that mailman offers, but there was certainly no
need to use it. I manage mailing lists that do, and ones that don't.
Personally, I'm in favor
On 5 May 2008, at 21:47, Scott Weeks wrote:
I have been waiting to send this, but please reconsider the Subject
line tag and the footer. It is very bothersome.
If given a choice, I would opt for neither. But I can't say that I am
especially bothered about either, either.
I don't
-- [EMAIL PROTECTED] wrote: --
On 5 May 2008, at 21:47, Scott Weeks wrote:
I have been waiting to send this, but please reconsider the Subject
line tag and the footer. It is very bothersome.
If given a choice, I would opt for neither. But I can't say that I am
especially
Just this alone Re: [Nanog-futures] is ~20 characters.
scott
___
Nanog-futures mailing list
Nanog-futures@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-futures
On May 5, 2008, at 10:31 PM, Gregory Hicks wrote:
From: Joe Abley [EMAIL PROTECTED]
On 5 May 2008, at 21:47, Scott Weeks wrote:
I have been waiting to send this, but please reconsider the Subject
line tag and the footer. It is very bothersome.
If given a choice, I would opt for neither.
On 5 mei 2008, at 0:57, Adrian Chadd wrote:
I'd seriously be looking at making current -software- run more
efficiently
before counting ipv6-related power savings.
Good luck with that.
Obviously there is a lot to be gained at that end, but that doesn't
mean we should ignore power use in
On 2 mei 2008, at 20:51, Mike Leber wrote:
Since nobody mentioned it yet, there are now less than 1000 days
projected
until IPv4 exhaustion:
http://www.potaroo.net/tools/ipv4/
Unfortunately that won't load for me over IPv6, path MTU black hole...
ps. 1000 days assumes no rush,
On Sun, 4 May 2008, Paul Vixie wrote:
[EMAIL PROTECTED] (Steve Gibbard) writes:
The right solution is to design the anycast servers to be as sure as
possible that the route will go away when you want it gone, but to have
multiple non-interdependent anycast clouds in the NS records for each
[EMAIL PROTECTED] (Steve Gibbard) writes:
... if each anycast cluster is really several servers, each using OSPF
ECMP, then you can lose a server and still have that cluster advertising
the route upstream, and only when you lose all servers in a cluster will
that route be withdrawn.
Hello All ,
On Mon, 5 May 2008, Paul Vixie wrote:
[EMAIL PROTECTED] (Steve Gibbard) writes:
...snip...
But yes, Joe's ISC TechNote is an excellent document, and was a big help
in figuring out how to set this up a few years ago.
and now for something completely different -- where in
On May 5, 2008, at 12:07 PM, Paul Vixie wrote:
But yes, Joe's ISC TechNote is an excellent document, and was a big
help
in figuring out how to set this up a few years ago.
and now for something completely different -- where in the
interpipes could
a document like that have been
On Mon, May 5, 2008 at 10:07 AM, Paul Vixie [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Steve Gibbard) writes:
... if each anycast cluster is really several servers, each using OSPF
ECMP, then you can lose a server and still have that cluster advertising
the route upstream, and only
After a request, I can confirm that Burma / Myanmar dropped off the
BGP tables here over the weekend :
bgp.sum.May_2_00:07:00_EDT_2008: AS 9988 MPT-
AP | 3 hops | as path 174 2914 9988
bgp.sum.May_2_00:07:00_EDT_2008: AS 18399 BAGAN-TRANSIT-
AS
On May 5, 2008, at 1:16 PM, David Andersen wrote:
On May 5, 2008, at 12:07 PM, Paul Vixie wrote:
But yes, Joe's ISC TechNote is an excellent document, and was a big
help
in figuring out how to set this up a few years ago.
and now for something completely different -- where in the
On 05 May 2008 16:07:03 +
Paul Vixie [EMAIL PROTECTED] wrote:
But yes, Joe's ISC TechNote is an excellent document, and was a big
help in figuring out how to set this up a few years ago.
and now for something completely different -- where in the interpipes
could a document like that
We had a very strange problem today. Two of our hosts could not reach
a server, but only those two hosts. All of our other hosts could reach
those servers fine. (OK, I didn't try ALL of our IPs, but the half
dozen I did try worked fine.)
I checked all of our firewalls and routers, and everywhere
On 2008-05-05, Paul Vixie [EMAIL PROTECTED] wrote:
also, in OSPF, ECMP is not optional, even though most BSD-based software
routers don't implement it yet (since multipath routing is very new.)
Some readers might be interested to know the exception to most here;
the OpenBSD kernel has supported
On May 6, 2008, at 12:59 AM, Steven M. Bellovin wrote:
If not, what should the criteria be for an official note of the
paper?
Perhaps it's an oversimplification, but can't those who wish to
publish such information simply deliver their papers at a NANOG
meeting (after acceptance by the
On Tue, 6 May 2008 01:19:36 +0700
Roland Dobbins [EMAIL PROTECTED] wrote:
On May 6, 2008, at 12:59 AM, Steven M. Bellovin wrote:
If not, what should the criteria be for an official note of the
paper?
Perhaps it's an oversimplification, but can't those who wish to
publish such
In the popular tradition of replying to my own post ...
It seems that this problem started right around the time I changed our
BGP configuration. I did:
config term
route-map att_out permit
set as-path prepend 19317 19317
exit
clear ip bgp 12.87.125.249 out
This change was to increase our
Did your inbound path change as a result? Sounds like a path asymmetry
issue might be involved.
Douglas K. Rand wrote:
In the popular tradition of replying to my own post ...
It seems that this problem started right around the time I changed our
BGP configuration. I did:
config term
[EMAIL PROTECTED] (Steven M. Bellovin) writes:
If not, what should the criteria be for an official note of the paper?
Perhaps it's an oversimplification, but can't those who wish to publish
such information simply deliver their papers at a NANOG meeting (after
acceptance by the
On 5 mei 2008, at 21:56, Mike Fedyk wrote:
So if you have a 10 Mbps connection you don't get to
send 14000 64-byte packets per second, but a maximum of 2500
packets per
second. So with 64-byte packets you only get to use 1.25 Mbps.
You have just cut out the VoIP industry, TCP setup, IM or
* [EMAIL PROTECTED] (Iljitsch van Beijnum) [Mon 05 May 2008, 10:09 CEST]:
PS. Am I the only one who is annoyed by the reduction in usable
subject space by the superfluous [NANOG]?
No, and I'm just as annoyed by the (non-McQ) footer with superfluous
information attached to each mail.
On 5
On 6/05/2008, at 8:02 AM, Iljitsch van Beijnum wrote:
Of course not. Like I said, as an average end-user with 10 Mbps you
get to send a maximum of 2500 packets per second. That's plenty to do
VoIP, set up TCP sessions or do IM. You just don't get to send the
full 10 Mbps at this size.
Hmm, I
On 6/05/2008, at 4:07 AM, Paul Vixie wrote:
i dearly do
wish that something like a service advertisement protocol existed,
that
did what OSPF ECMP did, without a router operator effectively giving
every
customer the ability to inject other customer routes, or default
routes.
This
On May 6, 2008, at 2:52 AM, Paul Vixie wrote:
delay, because nanog meetings only happen N times per year, so
an idea may have to wait months before it's widely circulated.
congestion,
because nanog meetings are of fixed duration and there is, and has
to be,
competition for the slots,
On 5 May 2008, at 20:50, Nathan Ward wrote:
Perhaps what would make more sense here is Foundry (F5, etc.) building
an anycast feature - anycast prefixes are withdrawn when a cluster
relying on that anycast prefix goes below a threshold.
I'm not sure exactly what feature is required, here.
On 6/05/2008, at 1:19 PM, Steven M. Bellovin wrote:
Steve? I assume you meant Paul
No, Steve Gibbard referred to not having control of routers, Paul
referred to customers.
--
Nathan Ward
___
NANOG mailing list
NANOG@nanog.org
29 matches
Mail list logo
