April 2001 - Test - lists.nanog.org

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

11 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 11 Apr '01

11 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

$200 for a paid market research interview on product for IP service providers
by Launch Pad 11 Apr '01

11 Apr '01

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 Richard A. Steenbergen 11 Apr '01

11 Apr '01

On Wed, Apr 11, 2001 at 04:40:33PM -0400, alex(a)yuriev.com wrote: > > > 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." Just because Cisco cannot implement it correctly does not mean the concept is flawed, any more then we should go back to rip because ospf isn't simple and cisco had a bug in it once... There is absolutily nothing wrong with the concept of distributing the forwarding table, so long as care is taken to insure synchronization, and you are not using a broke-ass IPC and a broke-ass bus which wasn't ever designed for it when you make the copy. "Math is hard, lets go shopping" -Barbie "Hate the vendor, not the routes" -Unknown -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

2 1

Re: MultiBind Testers Wanted
by woods＠weird.com 11 Apr '01

11 Apr '01

[ On Wednesday, April 11, 2001 at 08:05:14 (-0700), kevind(a)sea.checkpoint.com wrote: ] > Subject: Re: MultiBind Testers Wanted > > The term BIND, as DNS software, was never owned by Mike Karels or I. > Neather of us were the creators of BIND. At the time we work on BIND, > our work was owned by UCB. The original creators of BIND were Douglas > Terry, Mark Painter, David Riggle and Songnian Zhou. They were > working on their graduate degrees in Computer Science at UCB. The > first published paper about BIND is in the Proceeding of Summer USENIX > Conference 1984, Salt Lake City. Oh my! I missed that reference! Thank you very much for correcting me! > I am not a lawyer but I could see that at some point the UCB Copyright > would expire and that the ISC copyright would then pick up the term. I think Vixie was alluding more to the trademark than the copyright. I expect that in terms of copyright he, and/or ISC, own large chunks of the BIND-8 code, and most of the BIND-9 code and documentation; though unless they've received waivers from all contributors the whole thing could get rather messy if anyone ever contested it. Certainly I never signed any waivers for my contributions to BIND-4 (though they were implicitly freely redistributable, of course). -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

3 2

RE: solar flares effecting anyone else?
by Segal, Mark 11 Apr '01

11 Apr '01

We were losing approx. 40 xDSL circuits at one time for a few days last week.. No problem this week.. It has Cisco and Me stumped. mark -- Mark Segal Director, Data and Internet Planning Axxent Corp. Tel: (416)907-2858 > -----Original Message----- > From: Jim Mercer [mailto:jim@reptiles.org] > Sent: Wednesday, April 11, 2001 4:46 PM > To: nanog(a)merit.edu > Subject: solar flares effecting anyone else? > > > > > 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 ] >

1 0

MED stability
by Swinton, Jeff 11 Apr '01

11 Apr '01

I've seen a lot of messages lately on making BGP scale better in order to increase the stability on the Internet. I do have one suggestion for a lot of ISPs out there. Unless you know that someone is listening to your MEDs, don't send them. Most ISPs don't listen to them and due to address aggregation most ISPs don't announce MEDs correctly (yes, there are some that do it right). By sending MEDs to folks that aren't listening, you're IGP instability unnecessarily contributes to the overall BGP instability. I personally have always taken the attitude that I'll announce MEDs to everyone, and if they listen they listen. At the time, I didn't realize the interaction between damping and MEDs. A changing MED value counts as a flap (actually half a flap) on both Cisco and Juniper routers. Overwriting incoming MEDs on a Cisco will prevent a changing MED from contributing to damping, but a changing MED on a Juniper will contribute to damping regardless of whether or not it's overwritten.. I don't necessarily want to debate whether or not this behavior is correct, take that up with the vendors. I do want to say that the amount of BGP churn for your routes could dramatically decrease if you stop sending MEDs. To clarify, I'm referring to MEDs based upon IGP distance...MEDs with static values don't change and thus don't cause a problem. In addition, Cisco will actually wait 10m before propagating the MED change which decreases the potential churn a bit. Jeff

1 0

IPv6 - Ottawa, May 14-16
by Hovey, Richard 11 Apr '01

11 Apr '01

I'd like to call the NANOG community's attention to an IPv6 conference taking place in Ottawa, Canada, next month: Global IPv6 Summit May 14-16 Fairmont Chateau Laurier Ottawa, Ontario, Canada This Summit will report the latest updates on operational IPv6 activities: - IPv4-IPv6 coexistence and transition experiences - pilot deployments and leadership military programs - major initiatives in Japan and Korea where IPv6 is government policy. Other high interest topics include: - 3G wireless and IPv6 - commercial IPv6-ready products and services - IPv6 hot issues including the Forum's RFQ for open source DNS. Find the details on the summit beginning at http://www.ipv6forum.com. To take advantage of the IPv6 Forum's Discounted Room Rates, we urge you to make your hotel reservation by Friday, April 13. See to http://www.foretec.com/IPv6-hotel.html Global IPv6 Summits are organized by the IPv6 Forum and endorsed by the Internet Society. They are staged in various locations around the world to provide the industry and market with the best available information on this rapidly advancing technology. Thanks for your attention, Richard Hovey IPv6 Forum

1 0