Convergence, and our "lust" to throw TDM/ATM infrastructure in the garbge
is an area very near and dear to my heart.
I apologize if I am being a bit redundant here... but from our
perspective, we are an ISP that is under a lot of pressure to deploy a
VoIP solution. I just don't think we can... I
On (25/02/04 16:30), Steve Gibbard wrote:
>
> With that in mind, how much in the way of reliability problems is it
> reasonable to expect our users to accept?
probably something more than we tell them it will be down, but less than
we would (secretly) hope - most users tend to complain if it beco
> code problems from time to time, and the typical root server hicups.
Which hicups are those?
Thanks for pointing that out. That was the wrong way to describe my standpoint.
Frequent changes in DNS across the board, including edge servers
make connections seem non-working, when in reality it is a mis-configured DNS zone. So
whether
Dee
>-Original Message-
>From: Joe Abley [m
On 26 Feb 2004, at 08:46, W.D.McKinney wrote:
I think the Internet is doing pretty well save some IOS code problems
from time to time, and the typical root server hicups.
I'm interested to know what you mean by "typical root server hicups".
I'm trying to think of an incident which left the Int
It needs to be as reliable as the services that depend on it.
E.g. if bank A is using the Internet exclusively without
leased line back up to run its ATMs, or to interface with
its customers, then it needs to be VERY reliable.
If it's just my kid checking his email on AOL, probably
not that reli
>-Original Message-
>From: Steve Gibbard [mailto:[EMAIL PROTECTED]
>Sent: Thursday, February 26, 2004 12:30 AM
>To: [EMAIL PROTECTED]
>Subject: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
>>So, it appears that among general infrastructure we depend on,
Having woken up this morning and realized it was raining in my bedroom
(last night was the biggest storm the Bay Area has had since my house got
its new roof last summer), and then having moved from cleaning up that
mess to vacuuming water out of the basement after the city's storm sewer
overflowe
[ nick has trouble posting, so ... ]
Date: Wed, 25 Feb 2004 00:27:00 -0500
From: Nick Feamster <[EMAIL PROTECTED]>
Subject: Re: New Draft Document: De-boganising New Address Blocks
To: [EMAIL PROTECTED]
User-Agent: Mutt/1.4.1i
On Tue, Feb 24, 2004 at 06:28:48PM +0100, Daniel Karrenberg wrote:
>
Anyone at sprint care to shed some light on a latency
issue that's been going on since December?
(While the SLA credits are always nice, there's
something to be said for actually getting the traffic
from A to B!)
sl-bb20-fw>ping 144.228.241.75
Type escape sequence to abort.
Sending 5, 100-by
They're still in business. They've been bought out, but they're still
there.
Curtis
On Tue, 24 Feb 2004, Sameer Khosla wrote:
> Just to add my 2 cents, I have installed a lot of Openroute routers over the
> years, and have had virtually no problems with them. There is a GTX 1000
> Model t
David Meyer wrote:
No doubt. However, the problem is: What constitutes
"unnecessary system complexity"? A designed system's
robustness comes in part from its complexity. So its not
that complexity is inherently bad; rather, it is just
that you wind up with extreme sensitivity to outlying
e
On Wed, 2004-02-25 at 20:16, Bora Akyol wrote:
> This train of thought works well for only accidental failures,
> unfortunately
> if you have an adversary that is bent on disturbing communications
> and damaging the critical infrastructure of a country, physical faith
> sharing
> makes things les
Yesterday we witnessed a large scale failure that has yet to be
attributed to configuration, software, or hardware; however one need
look no further than the 168.0.0.0/6 thread, or the GBLX customer who
leaked several tens of thousands of their peers' routes to GBLX shortly
This should be rewritte
Petri,
>> I think it has been proven a few times that physical fate sharing is
>> only a minor contributor to the total connectivity availability while
>> system complexity mostly controlled by software written and operated by
>> imperfect humans contribute a major share to end-to-end
> >
> I think it has been proven a few times that physical fate sharing is
> only a minor contributor to the total connectivity availability while
> system complexity mostly controlled by software written and
> operated by
> imperfect humans contribute a major share to end-to-end availabilit
On Wed, 2004-02-25 at 13:34, David Meyer wrote:
> Is it that sharing fate in the switching fabric (as
> opposed to say, in the transport fabric, or even
> conduit) reduces the resiliency of a given service (in
> this case FR/ATM/TDM), and as such poses the "danger"
[EMAIL PROTECTED] (Jared Mauch) writes:
> ...
> I keep hear of Frame-Relay and ATM signaling that is going
> to happen in large providers MPLS cores. That's right, your "safe" TDM
> based services, will be transported over someones IP backbone first.
One of my DS3/DS1 vendors recently tol
Jared Mauch wrote:
On the sunny side, I see this improving over time. Software
bugs will be squashed. Poorly designed networks will be reconfigured to
better handle these situations.
The trend running against these points is the added features and
complexity into the software due to market
>From Jared:
> I keep hear of Frame-Relay and ATM signaling that is
> going to happen in large providers MPLS cores. That's right,
> your "safe" TDM based services, will be transported over
> someones IP backbone first.
> This means if they don't protect their IP network, the TDM
> ser
Is it that sharing fate in the switching fabric (as
opposed to say, in the transport fabric, or even
conduit) reduces the resiliency of a given service (in
this case FR/ATM/TDM), and as such poses the "danger"
you describe?
Sharing fate in the physical
On Wed, Feb 25, 2004 at 10:34:55AM -0800, David Meyer wrote:
> Jared,
>
> >> > Is your concern that carrying FR/ATM/TDM over a packet
> >> > core (IP or MPLS or ..) will, via some mechanism, reduce
> >> > the resilience of the those services, of the packet core,
> >> > of both, or somet
David Meyer wrote:
Is this an accurate characterization of your point? If
so, why should sharing fate in the switching fabric
necessarily reduce the resiliency of the those services
that share that fabric (i.e., why should this be so)? I
have some ideas, but I'm interested in what ideas other
I'm saying that if a network had a FR/ATM/TDM failure in the past
it would be limited to just the FR/ATM/TDM network. (well, aside from
any IP circuits that are riding that FR/ATM/TDM network). We're now
seeing
the change from the TDM based network being the underlying network to
the
"IP/MPLS
Jared,
>> >Is your concern that carrying FR/ATM/TDM over a packet
>> >core (IP or MPLS or ..) will, via some mechanism, reduce
>> >the resilience of the those services, of the packet core,
>> >of both, or something else?
>>
>> I'm saying that if a network had a FR/AT
In message <[EMAIL PROTECTED]>, Jared Mauch writes:
>
> (I know this is treading on a few "what if" scenarios, but it could
>actually mean a lot if we convert to a mostly IP world as I see the trend).
>
I think your analysis is dead-on.
--Steve Bellovin, http://www.research
At 10:52 AM 2/25/2004, you wrote:
recommendation come out regarding VoIP calls. How long until a simple
power failure results in the inability to place calls?
We're already at that point. If the power goes out at home, I'd have to
grab a flashlight and go hunting for a regular ol' POTS-powered
On Wed, Feb 25, 2004 at 09:44:51AM -0800, David Meyer wrote:
> Jared,
>
> >>I keep hear of Frame-Relay and ATM signaling that is going
> >> to happen in large providers MPLS cores. That's right, your "safe" TDM
> >> based services, will be transported over someones IP backbone first.
>
Jared,
>> I keep hear of Frame-Relay and ATM signaling that is going
>> to happen in large providers MPLS cores. That's right, your "safe" TDM
>> based services, will be transported over someones IP backbone first.
>> This means if they don't protect their IP network, the TDM servic
Ok.
I can't sit by here while people speculate about the possible
problems of a network outage.
I think that most everyone here reading NANOG realizes that
the Internet is becoming more and more central to daily life even
for those that are not connected to the internet.
If an IP-based system lets you see the status of the 23 hospitals in San
Antonio graphically, perhaps overlaid with near-real-time traffic
conditions, I'd rather use it as primary and telephone as secondary.
Counting on it? No. Gaining usability from it? You betcha.
Brian Knoblauch wrote:
So cmon, forget the statement, anyone know what actually happened.. ?
Steve
On Wed, 25 Feb 2004, Pete Templin wrote:
>
>
> Are you sure no one died as a result? My hobby is volunteering as a
> firefighter and EMT. If Level3's network sits between a dispatch center
> or mobile data termina
Are you sure no one died as a result? My hobby is volunteering as a
firefighter and EMT. If Level3's network sits between a dispatch center
or mobile data terminal and a key resource, it could be a factor
(hospital status website, hazardous materials action guide, VoIP link
that didn't rero
>> Timothy Brown wrote:
>> I disagree with the view that it is a hack.
>> It's no more a hack than using a DNS feed;
>I concur with this. Besides, from the pragmatic side of the "consumer",
>if it does solve a problem (albeit short or medium term) I don't care
>much if it's a "hack".
Then we all
34 matches
Mail list logo
