> From where i'm sitting, I see a number of potentially
> dangerous trends that could result in some quite catastrophic
> failures of networks. No, i'm not predicting that the
> internet will end in 8^H7 days or anything like that. I
> think the Level3 outage as seen from the outside
> If events are not properly triggered back upstream (ie:
> adjencies stay up, bgp remains fairly stable) and you end up
> dumping a lot of traffic on the floor, it's sometimes a bit
> more dificult to diagnose than loss of light on a physical path.
>
> On the sunny side, I see thi
On Thu, Feb 26, 2004 at 11:28:09AM +, [EMAIL PROTECTED] wrote:
>
> > Wouldn't it be great
> >if routers had the equivalent of 'User mode Linux' each process
> >handling a service, isolated and protected from each other. The
> >physical router would be nothing more than a generic kernel ha
>> This is possible today. Build your own routers using
>> the right microkernel, OSKIT and the Click Modular Router
>> software and you can have this. When we restrict ourselves
>> only to router packages from major vendors then we are
>> doomed to using outdated technology at inflated prices.
On Thu, 26 Feb 2004 14:48:55 GMT, [EMAIL PROTECTED] said:
> History shows that if you can build a mousetrap that is technically
> better than anything on the market, your best route for success is
> to sell it into niche markets where the customer appreciates the
> technical advances that you can
On Thu, Feb 26, 2004 at 02:48:55PM +, [EMAIL PROTECTED] wrote:
>
> >> This is possible today. Build your own routers using
> >> the right microkernel, OSKIT and the Click Modular Router
> >> software and you can have this. When we restrict ourselves
> >> only to router packages from major ven
--- vijay gill <[EMAIL PROTECTED]> wrote:
> How would you know this? Historically, the cutting
> edge technology
> has always gone into the large cores first because
> they are the
> ones pushing the bleeding edge in terms of capacity,
> power, and
> routing.
>
> /vijay
I'm not sure that I'd a
On Thu, Feb 26, 2004 at 10:05:03AM -0800, David Barak wrote:
>
> --- vijay gill <[EMAIL PROTECTED]> wrote:
> > How would you know this? Historically, the cutting
> > edge technology
> > has always gone into the large cores first because
> > they are the
> > ones pushing the bleeding edge in term
>> 1) their backbones currently "work" - changing them
>> into something which may or may not "work better" is a
>> non-trivial operation, and risks the network.
i would disagree. their backbone tend to reach scaling problems, hence the
need for bleeding/leading edge technologies. that's been m
vijay gill wrote:
CEF was designed to support offloading the RP.
Not really. There existed distributed fastswitching before DCEF came
along. It might still exist. CEF was developed to address the issue of
route cache insertion and purging. The unneccessarily painful 60 second
interval new d
On Thu, Feb 26, 2004 at 09:32:07PM +0200, Petri Helenius wrote:
> along. It might still exist. CEF was developed to address the issue of
> route cache insertion and purging. The unneccessarily painful 60 second
> interval new destination stall was widely documented before CEF got
> widespread
--- vijay gill <[EMAIL PROTECTED]> wrote:
> In all of the above cases, those were the large isps
> that forced
> development of the boxes. Most of the smaller
> "cutting edge"
> networks are still running 7513s.
>
Hmm - what I was getting at was that the big ISPs for
the most part still have a
> History shows that if you can build a mousetrap that is technically
> better than anything on the market, your best route for success is
> to sell it into niche markets where the customer appreciates the
> technical advances that you can provide and is willing to pay for
> those technical advanc
and this has been so well shown by the blazing successes of
bay networks, avici, what-its-name that burst into flames in
everyone's labs, ...
That's a very good point. Building a router that works (at least
learning from J's example) is hiring away the most important talent
from your competition.
> Wouldn't it be great
>if routers had the equivalent of 'User mode Linux' each process
>handling a service, isolated and protected from each other. The
>physical router would be nothing more than a generic kernel handling
>resource allocation. Each virtual router would have access to x amou
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
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.
35 matches
Mail list logo
