- NANOG - lists.nanog.org

CLEC Compensation appeal
by Henry R. Linneweh 12 Apr '01

12 Apr '01

US Supreme Court to Review State Telecom Case http://www.clec-planet.com/legal/cappuccio4-9.html -- Thank you; |---------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | | working group | | Resilient Packet Transport | | http://www.luminousnetworks.com | |---------------------------------| Henry R. Linneweh

1 0

Re: OT:Optical Splitters
by Martin Hannigan 12 Apr '01

12 Apr '01

As far as I know they aren't power, but they inject loss as a termination device. It should be a "wiring" issue. Feel free to ping me offline if you need more detail. The primary/protect is an equipment characteristic, not a splitter characteristic. You do have to "watch out" for providers that "forget" to drop in the protect or neglect to mention it, or charge more. It also depends where your gear is slung off the network i.e. a spur or a lateral to the network. -M At 11:09 PM 4/11/2001 -0400, Martin, Christian wrote: >Folks, > >Sorry for the slightly off-topic post. Is anyone familiar with optical >splitters that can run in a primary-backup mode in a passive way? The >intent is to provide GigE redundancy between a host and a pair of switches. >It needs to be able to switch over on a loss-of-link condition, and >preferably switch back once the primary comes online. Does such a thing >exist that runs without power? If not, is there a manageable, rackmount >solution with telco-grade reliability? > >TIA, >chris Regards, -- Martin Hannigan hannigan(a)fugawi.net Fugawi Networks Founder/Director of Implementation Boston, MA http://www.fugawi.net Ph: 617.742.2693 Fax: 617.742.2300

1 0

Re: solar flares effecting anyone else?
by Sean Donelan 12 Apr '01

12 Apr '01

On Wed, 11 April 2001, John Todd wrote: > From a terrestrial perspective, the recent solar flare activity would > have a much more noticeable effect on circuits that have long, > inductive (copper) loops that collect those pesky electron charges. > In North America, I imagine that this is mostly local loop issues, > since the majority (everything?) that is of any appreciable distance > is fiber. It is perhaps the case that the Canadians and Alaskans may > see more of an issue even on their short local loops, since the more > polar segments of the Earth bear the brunt of the storms (if I recall > my astronomy courses correctly.) April 2, 2001 Sol Solar flare April 3, 2001 Phoenix, AZ Under Investigation (Qwest) April 3, 2001 Elkton, MD Fiber Cut (ATT) April 3, 2001 Columbus, GA Under Investigation (Bellsouth) April 4, 2001 Northeastern US Power supply (Sprint) April 5, 2001 Dullas, VA Power supply (AOL/TW) April 6, 2001 Joilet, IL Power supply (Ameritech/SBC) April 6, 2001 Alamagorda, NM Fiber cut (Qwest) April 6, 2001 Jacksonville, FL Under investigation (Bell South) April 8, 2001 Loredo, TX Power supply (Southwestern Bell) Its probably not statistically significant, but the hit on power supplies after the recent solar flare did catch my eye. I don't recall a similar rise occuring in the past. But I can't compare the number of power supply problems to the same period last year because ATIS Network Reliability Steering Committee has removed all of its public reports from its free portion of the web site, and I don't really want to spend $50 to buy a copy.

1 0

solar flares effecting anyone else?
by Jim Mercer 12 Apr '01

12 Apr '01

i've got an E1 circuit that goes: Toronto -> Amsterdam (fiber) Amsterdam -> Islamabad (satelite) Islamabad -> Karachi (fiber) for the last couple days, my router has been seeing an abnormally high number of "carrier transitions". a parse of the log shows 400+ UPDOWN syslog messages from the cisco for today (4:pm Eastern), and some 400 for yesterday. prior to that maybe 0-10 a day. i've openned a ticket with the circuit provider, but by asking the list, i was hoping to be prepared for a "must be solar flares" excuse. -- [ Jim Mercer jim(a)pneumonoultramicroscopicsilicovolcanoconiosis.ca ] [ Reptilian Research -- Longer Life through Colder Blood ] [ aka jim(a)reptiles.org +1 416 410-5633 ]

4 6

RE: gigabit router (was Re: Getting a "portable" /19 or /20)
by alex＠yuriev.com 12 Apr '01

12 Apr '01

> CEF is not the only mechanism to implement distributed forwarding > (within or without Cisco for that matter), and to say that distributed > forwarding is faulty because of software complexities of one > manufacturer, whose code base is built upon on a monolithic core (to use > operating system would lower what it means to actually be a operating > system) is to generalize all failures to a distributed architecture > where the fault does not _always_ lie. CEF and dCEF periodically break on Cisco. They break in the most interesting ways - the debugging indicates that the packets are going one way when they in reality are going the other way. Without CEF or dCEF Cisco's are useless for the amount of traffic that I am interested in. Juniper is very interesting. The only problem is a gazillion strange things that it tries doing. Juniper's BGP has very intereting bugs in confederations which I have discovered on the day #1 of putting one of them into production. That bug is still not fixed. Since confederations are very widely used, and no one else found this bug, and yet we have hit it nearly immediately, there is some sort of logical problem here. If something as simple as AS_PATH prepending in confederations does not work, I have some big reservations about things that are much more complex than that. Nortel has some exellent hardware that they have inherited from Bay Networks. Unfortunately, they still have not written the software to take any advantage of it, nor they developed it to the level where it can actually complete with the new offerings from the other vendors. Thanks, Alex > While a central architecture is simple, it has been shown within and > beyond the industry that it does not scale. > > David > > > -----Original Message----- > From: alex(a)yuriev.com [mailto:alex@yuriev.com] > Sent: Wednesday, April 11, 2001 1:41 PM > To: nanog(a)merit.edu > Subject: RE: gigabit router (was Re: Getting a "portable" /19 or /20) > > > > > > > Vendors have known how to solve this problem for many years. > > Failure to do so is a poor implementation and has nothing to do > > with centralized forwarding being better/worse than distributed > > forwarding. > > Yet another person who does not understand the KISS principle. I am > sure in theory it all works great, though I am seeing way too many > comments > similiar to: > > "The connectivity issues have been resolved. This appears to be the > same > CEF related issues we experienced Monday evening, and we have a case > open > with Cisco. As we get more information from Cisco, we will be passing > it > along." > > Alex > > >

2 3

OT:Optical Splitters
by Martin, Christian 12 Apr '01

12 Apr '01

Folks, Sorry for the slightly off-topic post. Is anyone familiar with optical splitters that can run in a primary-backup mode in a passive way? The intent is to provide GigE redundancy between a host and a pair of switches. It needs to be able to switch over on a loss-of-link condition, and preferably switch back once the primary comes online. Does such a thing exist that runs without power? If not, is there a manageable, rackmount solution with telco-grade reliability? TIA, chris

1 0

RE: gigabit router (was Re: Getting a "portable" /19 or /20)
by Roeland Meyer 12 Apr '01

12 Apr '01

> From: Craig Partridge [mailto:craig@aland.bbn.com] > Sent: Wednesday, April 11, 2001 2:00 PM > > In message <20010411164727.B647(a)alcor.net>, Matt Zimmerman writes: > > >I think Alex was referring to internal consistency within > >the router (between linecards), not external consistency. > >For example, if linecard X believes that a packet should be > >forwarded to linecard Y, but linecard Y's forwarding table > >is older than X's, Y could misforward the packet, causing a > >forwarding loop or a dropped packet. Thus, it can be the > >case that neither the old path nor the new path is taken. > > I used to give a course on building high speed routers. A > section of the > course was entitled "common mistakes to avoid." One of them > was precisely this problem. The rule is forward once within a box > -- if linecard X has decided how a packet is to be forwarded, > linecard Y shouldn't be reconsidering the decision. > (And, in fact, if you look at most linecard designs, the > output path, from switch to transmission, does > not include a forwarding engine > -- there's only a forwarding engine on the inbound path). I don't think that this was the stated case. The original proposal was to make the decision within the core router and export the policy implementation to each line-card as a table. Yes, you lose the ability to make some dynamic decisions this way unless you make linecards intelligent enough to interpret policies. The problem then becomes one of synchronizing the tables within the line-cards with the core. That is where the consistency problem arrives. I submit that, this is no different from the macro-system where, edge routers have to be updated with core2edge policies. We have consistency problems there to. However, they are transient and the system is robust enough to handle those transients. I further submit that this same approach can be applied at the micro-system, internally to a specific router implementation. There exist single-chip PC systems that could do this (www.zflinux.com) One each, per line-card, with their own individual PCI bus. They can talk to each other via the directly connected bus. What we then have is a closely-coupled distributed computing cluster ... in one box. Now, we have macro-architectures being applied to micro-systems. Throw in a couple of ASICs and you have an intelligent line-card, that is the equivalent of a full PC, with its own *nix O/S. Prices are dropping on this stuff daily.

1 0

RE: gigabit router (was Re: Getting a "portable" /19 or /20)
by Martin, Christian 12 Apr '01

12 Apr '01

As I understand it, the real problem with centralized forwarding architectures (and electrical forwarding architectures in general) is memory access speed. The total throughput of the router cannot exceed the memory access speed. Even if there was a way to process packets (lookup/decrement/move across bus, etc) at OC-192 rates in a single instruction at infinite speed (1EHz, say), the packet must be written into and out of memory. Given 1ns (possible today?) read/write times, and assuming 64 byte cell-based packet read/writes for efficiency, you can write 64*8/1ns = 512,000,000,000 bits/sec. Divide by 2 (read/write) = 256Gbps Which is equivalent to 25 OC-192s at line rate. Or, 8 OC-768s at line rate. But since my initial assumptions are currently impossible, then the results are also not possible using centralized forwarding. For example, by doubling the memory speed, we lose 12 OC-192s! I would expect even those vendors that use centralized forwarding engines to go to distributed ones in order to achieve OC-768. After that, who knows. Memory needs to me accessed in the picosecond speed range. I think that optical switches will be in place before core OC-3072 and higher links come online. my $.02, chris > > You misunderstand. Getting multiple forwarding tables synchronized > on one box IS simple, if the architecture considered it from > the start. > Trying to bolt it on later can cause problems, however. These > problems are an implementation issue on a particular platform. > > As a counterpoint to what you say, consider that all commonly > deployed routers that can handle OC-192 rates do NOT have a > single centralized forwarding engine. > > Or do you know something about KISS that was not apparent to > those who designed these working products? > > Prabhu > > > > -----Original Message----- > > From: alex(a)yuriev.com [mailto:alex@yuriev.com] > > Sent: Wednesday, April 11, 2001 4:41 PM > > To: nanog(a)merit.edu > > Subject: RE: gigabit router (was Re: Getting a "portable" > /19 or /20) > > > > > > > > > > > > Vendors have known how to solve this problem for many years. > > > Failure to do so is a poor implementation and has nothing to do > > > with centralized forwarding being better/worse than distributed > > > forwarding. > > > > Yet another person who does not understand the KISS principle. I am > > sure in theory it all works great, though I am seeing way too > > many comments > > similiar to: > > > > "The connectivity issues have been resolved. This appears to > > be the same > > CEF related issues we experienced Monday evening, and we have > > a case open > > with Cisco. As we get more information from Cisco, we will > > be passing it > > along." > > > > Alex > > > > > > >

1 0

RE: $200 for a paid market research interview on product for IP s ervice providers
by Jade E. Deane 11 Apr '01

11 Apr '01

Try the INET-ACCESS list... lots of starving network artisans there. Jade -----Original Message----- From: Launch Pad [mailto:scottlaunchpad@yahoo.com] Sent: Wednesday, April 11, 2001 3:23 PM To: nanog(a)merit.edu Subject: $200 for a paid market research interview on product for IP service providers We are conducting market research on a new services provisioning and management platform for IP service providers which helps providers develop, deploy, and manage premium priced, value-added services aimed at the corporate market. We will pay you, your company or a leading charity of your choice $200 to participate in a 45-minute telephone research interview to discuss this new service concept. About our company and the interview We are a market research and consulting firm specializing in enterprise and Internet software and services. We conduct hundreds of interviews every year with key decision-makers like you to understand the potential for new products and services. Brief introduction to the product we'll be discussing A new services provisioning and management platform for IP service providers, which helps service providers develop, deploy, and manage premium priced, value-added services aimed at the corporate market. We are speaking with decision-makers for services of this type to better understand their needs and to help shape our client's strategy. To qualify for the interview, you are: Director/VP in Network Operations / Engineering / IP Services In this interview we will NOT: Try to sell you anything. We are conducting market research to shape our client's marketing strategy. Quote you publicly, only in a private report to our client. Your company and name can be disguised in the report, if you wish. If you are interested: Please reply ASAP by phone at (415) 252-7751 or send me an email Suggest several times that are convenient for you and the phone number(s) where you can be reached. I will reply promptly to confirm a specific time. We can conduct the interviews any day, 7am - 7pm PST until Friday, April 20th. We can interview you at your home or office. Thank you. Scott Brooks Research Analyst Launch Pad T: 415-252-7751 F: 509-692-5552 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

RE: gigabit router (was Re: Getting a "portable" /19 or /20)
by Kavi, Prabhu 11 Apr '01

11 Apr '01

You misunderstand. Getting multiple forwarding tables synchronized on one box IS simple, if the architecture considered it from the start. Trying to bolt it on later can cause problems, however. These problems are an implementation issue on a particular platform. As a counterpoint to what you say, consider that all commonly deployed routers that can handle OC-192 rates do NOT have a single centralized forwarding engine. Or do you know something about KISS that was not apparent to those who designed these working products? Prabhu > -----Original Message----- > From: alex(a)yuriev.com [mailto:alex@yuriev.com] > Sent: Wednesday, April 11, 2001 4:41 PM > To: nanog(a)merit.edu > Subject: RE: gigabit router (was Re: Getting a "portable" /19 or /20) > > > > > > > Vendors have known how to solve this problem for many years. > > Failure to do so is a poor implementation and has nothing to do > > with centralized forwarding being better/worse than distributed > > forwarding. > > Yet another person who does not understand the KISS principle. I am > sure in theory it all works great, though I am seeing way too > many comments > similiar to: > > "The connectivity issues have been resolved. This appears to > be the same > CEF related issues we experienced Monday evening, and we have > a case open > with Cisco. As we get more information from Cisco, we will > be passing it > along." > > Alex > > >

2 1