On Sat, 29 May 2004, Eric Kuhnke wrote:
> When 12016s are on ebay for $12,000, even a low budget "tier 3" can
> afford proper routing gear... It's not as if the Internet is still
> powered by 7507s! (Well, a large part still is. :-)
12016 will only do OC48 speeds and the OC48 cards that use
interesting reading
http://mail.internet2.edu:8080/guest/archives/qbone-arch-dt/log200205/msg0.html
regards,
/vicky
Edward B. Dreger wrote:
GC> Date: Sat, 29 May 2004 16:53:17 -0400
GC> From: Gordon Cook
GC> The point I am making in my report is NOT that the best
GC> effort network has tech
GC> Date: Sat, 29 May 2004 16:53:17 -0400
GC> From: Gordon Cook
GC> The point I am making in my report is NOT that the best
GC> effort network has technology problems but rather that it has
GC> ECONOMIC PROBLEMS. That it might support 2 or 3 players not
GC> 2 or 3 HUNDRED.
Best effort is cheap
Could somebody from ICG please contact me off-list?
Tier 1 operators do not do "best effort" really, at least not in their
cores (and they have the SLAs to back it up). They buy hugely expensive
top notch gear (Cisco 12000 (and now CRS:s) and Junipers) to get the big
packet buffers, the fast reroutes and the full routing table lookups for
each pack
On Sat, 29 May 2004, Gordon Cook wrote:
> discussing. We don't pretend that QoS is easy or any kind of mature
> collection of technologies, but increasingly it looks as though the
Tier 1 operators do not do "best effort" really, at least not in their
cores (and they have the SLAs to back it u
may I make just a passing observation?
From a technology point of view the best effort internet certainly
"works." Not surprisingly the comments here are primarily debating
the finer points of the technology.
The point I am making in my report is NOT that the best effort
network has technolo
On Sat, 29 May 2004, Edward B. Dreger wrote:
> Nitpicking: Latency isn't that important with unidirectional
> communication. However, VoIP users seem reasonably happy with
> current latency and jitter -- and the Internet still is _largely_
> xxTP, anyway... particularly if one ignores peer-to-p
MC> Date: Sat, 29 May 2004 14:26:01 -0400
MC> From: Matthew Crocker
MC> The PSTN does guarantee a certain service level, latency,
MC> call completion etc.
As do many Internet providers. (s/call completion/packet loss/)
MC> Latency & Jitter are very important when dealing with sound &
MC> vid
We used such system in Russia for many years, with a few exceptions:
-- did not used SNMP (because it is a sux!), used 'ssh/rsh router show ...'
commands instead;
- not top 10 traffic flows, but top 10 traffic flows + top 10 unusual
traffic flows.
Worked effectively.
>To bring this back on top
The PSTN doesn't offer guaranteed end-to-end transmission, and
certainly statmuxes based on expected load. Looks like similar
capacity planning.
The PSTN does guarantee a certain service level, latency, call
completion etc.
Perhaps you refer to latency. Most people don't care as long as
HTTP a
GC> Date: Fri, 28 May 2004 15:58:06 -0400
GC> From: Gordon Cook
GC> I published a two month issue last weekend with the bottom
GC> line conclusion that there can be no telecom recovery as
GC> long as the industry relies solely on the best effort
GC> business model which I believe is not economic
Sam,
>
> You can get the received routes via SNMP. I've done this manually on
> > occasion for the purposes of doing "what-if" analysis of potential
> > traffic plans - take a dump of all available external routes via SNMP,
> > apply to that the proposed policy with regard to selecting the best
>
>
> Per Gregers Bilse <[EMAIL PROTECTED]> wrote:
> > On May 28, 10:37am, "Sam Stickland" <[EMAIL PROTECTED]> wrote:
> >> Are there any BGP extensions that would cause a BGP
> speaker to foward
> >> all of it's paths, not just it best? I believe quagga had
> made some
> >> recent attempts
> >
On Fri, 28 May 2004, Bruce Pinsky wrote:
> But the "optimizing" device wouldn't be advertising multiple paths.
> It would be advertising its selected path from all viable paths
> based on the selection criteria/policy implemented by the user.
> The optimizing device can then keep track of wha
Per Gregers Bilse <[EMAIL PROTECTED]> wrote:
> On May 28, 10:37am, "Sam Stickland" <[EMAIL PROTECTED]> wrote:
>> Are there any BGP extensions that would cause a BGP speaker to
>> foward all of it's paths, not just it best? I believe quagga had
>> made some recent attempts
>
> It has been discussed
Are there any BGP extensions that would cause a BGP speaker to foward all of
it's paths, not just it best? I believe quagga had made some recent attempts
in this direction. IIRC the problem isn't to do with the route annoucements,
it's the route withdrawals. I believe BGP only specifies the prefix
Bruce Pinsky <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Per Gregers Bilse wrote:
>
>> On May 28, 10:37am, "Sam Stickland" <[EMAIL PROTECTED]> wrote:
>>
>>> Are there any BGP extensions that would cause a BGP speaker to
>>> foward all of it's paths, not just it
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
>> "Per" == Per Gregers Bilse <[EMAIL PROTECTED]> writes:
>
> Per> But that wasn't really the point. If I telnet to all border
> Per> routers and do 'sh ip b' I can get all tables too; likewise if I
> Per> have a starting point and do a lot of
19 matches
Mail list logo
