- NANOG - lists.nanog.org

Re: Traffic engineering tools
by Vadim Antonov 28 Oct '99

28 Oct '99

> You miss the point. As you well know, capacity is where it is, and not > where you need it. This is a pragmatic and practical problem that costs > people Real Money. Tony, there's more fiber in the ground than all routers together can fill up. And putting in fiber is not a highly skilled labour, quite unlike getting tons of buggy software to work in a production network. > I know one very large backbone operator who says something like "We couldn't >even begin to build our network without TE. It works and we must have it." Isn't it the same provider who's notorious for ATM-based network? If we think of the same provider - i had a pleasure of being a customer. Never again. > It's got nothing to do with latency and everything > to do with capacity. If you have the luxury of having fiber wherever and > whenever you want it, well, you're lucky. But not everyone is quite so > lucky. Luck is 99% a foresight. > I would claim that those _ARE_ real benefits. Numbers? > Perhaps it's not the elegant, desireable, or theoretically beautiful > solution. But it is a practical solution. Yes, sure. As Milo used to say: "With enough thrust even pigs will fly" :) > If you would like to wait for the elegant, desireable, and theoretically > beautiful solution, please be my guest. Those of us who engineer to reality > have more work to do. ;-) I'll simply remind you that there is also a > group of people waiting for the elegant, desireable, and theoretically > beautiful inter-domain routing protocol. I found that one cannot do IDR protocols for a living. Maybe, Yakov :) > Or..... it could be a requirement posed by the customer base that vendors > are trying to address. Yeah, sure. Like the conFusion. Or 7000 series. > You may not share in the problem. That's fine, I don't think anyone would > (ethically) suggest that you use a tool that solves a problem you don't > have. Unfortunately, the tool does not come free - any new code in a box makes the box flakier. And costlier. So what all these features do is shifting cost from those who screwed up network planning to those who did it properly, but have to pay for all bundled TE stuff and live with flaky complicated code. My memories of being dragged out of bed nearly every night because of router software being stuck in interesting ways are not particularly fond. I'll exchange complicated ultra-smart hot stuff for a dumb box which actually works - any time. --vadim

3 2

Re: Traffic engineering tools
by Vadim Antonov 28 Oct '99

28 Oct '99

Traffic Engineering is like Quality of Service - it doesn't create any more bandwidth by magic, and simply reallocates existing resources differently. That established, we have two courses of action - the first, is to bulild overcomplicated networks and then try to fix resulting suboptimal routing with TE. The second option is to simplify topologies by replacing clusters of routers with scalable and inherently fault-tolerant devices (guess which ones i have in mind :) In a long-distance backbone where routers connected directly to fibers, and where there's no overlay of level-2 topology, the cost of deliberate misrouting (sending packets down paths different from shortest) is simply too high to justify any benefits it brings. The intermediate virtual circuit layers simply obscure the fundamentals by making paths inherently non-optimal (if you do not plan to use SONET or ATM VCs to create topologies which do not match physical paths, why whould you want to install it?) Note that customers do not generally care about bandwidth. The name of the game is latency at a given load. Misrouting packets simply increases latency. So. Benefits of TE as compared with simpler and more robust techniques (such as adequate provisioning and capacity planning :) weren't demonstrated in practice. I have yet to see any real backbone operator saying something like "we've got 30% less latency because we do TE". I strongly suspect that is because there are no real measurable benefits - and that TE is being used mostly to cover up planning problems and as a short-term fix to idiocies at a transmission level. That is a very thin justification for replacing technology which is known to work with a very new can of worms. My personal theory on QoS and TE hoopla is that this is a FUD tactics used by Cisco to raise entry barriers for other vendors - and to con customers into buying more of their irrelevant ATM stuff. --vadim PS There were tons of research and articles on best methods of CPU and memory scheduling. In restrospective, building faster processors turned out to be the soultion. Even if they're 99% idle. Meanwhile, the vendors which were keen on doing detailed accounting stuff nearly all are history by now. >From: Jerry Scharf <scharf(a)vix.com> ... >I do believe that some of the TE folks are punting the general case >solution by only attempting to do TE and protection on a small potion of >their traffic. If you have a glut of web traffic that acts as a sponge, >you can get away with nonoptimal management of the subset without causing >meltdowns.

2 1

** ANNOUNCE -- New RADB Fee Structure **
by Craig Labovitz 27 Oct '99

27 Oct '99

RADB Fee Structure ------------------ Since 1995 Merit Network, Inc., has operated the RADB Internet Routing Registry as a free service to the community. Initial funding for the service came from the National Science Foundation as part of the Routing Arbiter project. In recent years, donations from a number of commercial Internet providers provided continued support for RADB operations. As Internet Routing Registry technology has matured, the RADB service has experienced explosive growth. Today, the RADB database handles well over a million queries a day from several thousand unique Internet end-sites. This growth in RADB usage, including a dramatically increased volume of email and telephone calls to the RADB help desk, has placed significant demands on RADB staff and equipment resources. In an effort to maintain the high level of RADB service as well as encourage the migration to a distributed database, Merit has implemented the following RADB fee structure: Beginning November 1, 1999, Merit Network, Inc., will begin charging RADB users a $200 yearly fee per maintainer object registered in the RADB Internet Routing Registry database. Credit card payment must be made by all RADB maintainer object owners within 60 days. Unpaid maintainer objects and all related objects will be disabled from the registry. Internet providers may register via the web by reading and accepting the Internet Routing Registry Maintainer Object Agreement, <https://www.radb.net/radb/agreement.html> and then by supplying the appropriate payment information. IMPORTANT: The registration fee for Internet providers PEERING with Route Server Next Generation <http://www.rsng.net> machines at the PAIX, Mae-East, Mae-West, AADS and PacBell exchange points is included as part of the RSNG service at these exchanges. Providers peering with the RSNG route servers at one or more of these five exchange points do *NOT* need to submit a $200 payment for any maintainer objects registered with their autonomous system number in the RADB. Alternatives to Registering in the RADB --------------------------------------- As an alternative to the RADB, Internet providers are welcome to maintain their own local registry. Several groups, including Merit Network, have recently developed RPSL-capable Internet Routing Registry database servers. These *FREELY* available IRR server daemons, including IRRd, provide a simple mechanism for providers to maintain a mirror of Internet registry data and a local repository of customer routing information. As part of the transition to RPSL and RPS-DIST, Merit now strongly encourages RADB users to begin operating their own local routing registries. Merit will continue to freely mirror and permit mirroring by other local ISP registries. For more information on running your own IRR registry, see: http://www.irrd.net http://www.ripe.net/db http://www.isi.edu/ra As an alternative to the RADB or running a local registry, RADB users may also choose to register in several alternative IRR databases. Several providers, including Cable & Wireless and Bell Canada, offer IRR registration service for their downstream customers. For a complete list of participating Internet Routing Registries, please see http://www.radb.net/list.html. More Information ---------------- For more information, please see the RADB web page at http://www.radb.net Or feel free to send email to db-admin(a)radb.net -- Craig Labovitz (425) 605-4296 (office) (425) 936-7329 (fax)

9 10

RE: Major asia pacific public exchange points
by K Dhanaseker 27 Oct '99

27 Oct '99

Hello, Data.com has compiled an article on the APIX . http://www.data.com/global_networks/backbones.html Though it is dated , might be a good starting point. There is another article on APIX peering w/ PAIX. http://www.data.com/story/DCM19990730S0001 Thanks ! Regards, Dhanaseker Network Engineer Trinus Corp Glendale,CA 91203 Ph: 908-230-2578 -----Original Message----- From: Sean Donelan To: nanog(a)merit.edu Sent: 10/26/99 3:34 PM Subject: Major asia pacific public exchange points What are the, or are there any, major international public exchange points in the Asia-Pacific region? I know about the wwww.ep.net web page listing lots of exchange points. For example, an exchange point with at least two multi-regional/multi-continent ISPs. Europe has the LINX, AMS-IX, dGIX, etc.

1 0

WC outage?
by Tatsuya Kawasaki 27 Oct '99

27 Oct '99

It appeared WC is experiencing some major outage somewhere. Any idea? Tatsuya /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Tatsuya Kawasaki KIVEX.com (Division of Allegiance Telecom) Unlock the Power of the Internet http://www.kivex.com Phone 301.215.6777 Fax 301.215.5991 Affiliation given for identification not representation /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

2 1

WC fiber cut at GA.
by Tatsuya Kawasaki 27 Oct '99

27 Oct '99

According to WC, it happened about 3 hours ago. I have no other info. any info? Tatsuya /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Tatsuya Kawasaki KIVEX.com (Division of Allegiance Telecom) Unlock the Power of the Internet http://www.kivex.com Phone 301.215.6777 Fax 301.215.5991 Affiliation given for identification not representation /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1 0

Re: Major asia pacific public exchange points
by Hyunseog Ryu/Brookfield/Norlight 27 Oct '99

27 Oct '99

MAEMURA Akinori <maem(a)mesh.ad.jp>@merit.edu on 10/26/99 10:18:09 PM Sent by: owner-nanog(a)merit.edu To: bmanning(a)vacation.karoshi.com cc: nanog(a)merit.edu (bcc: Hyunseog Ryu/Brookfield/Norlight) Fax to: Subject: Re: Major asia pacific public exchange points Bill, Thanks for the reply, :"bmanning(a)vacation.karoshi.com" wrote : at Tue, 26 Oct 1999 20:21:35 -0700 (PDT) ..... : :| > :| I think there's also one in Seoul called KIX as well, but I'm not entirely :| > :| sure. :| > :| > Yes, KIX is in Seoul but I think it is domestic IX. In :| > Japan as well there is no IXes which can be called :| > international one. :| :| As I understand, KIX is mostly domestic Korea. >Yes. Exact name is KTIX. Because of naming conflict, they are called KTIX. But I think they are doing Asia-Pacific Hub or something like that. Actually they have two kinds of backbone. One is for transit servier, Internet eXcange Point including international connection. Another is for domestic connection. In South Korea, they have 4 kinds of IX. One is KTIX running by Korea Telecom. Other things is DIX running by DaCom (A.K.A. BORA-Net) and Inet IX(maybe KINX?) running by I-Net Technology. DaCom IX and KIX is bigger. But three are carrying the several international connection. I heard that NCA (National Computing Agency?, parent organization of KRNIC) tried to maintain International eXchange Point for other ISP, so called KIX-NCA. But I'm not sure. It's 2 year's old information. I left South Korea at the time. You can contact with South Korea NOG group. http://www.nog.or.kr mailto:nog@nog.or.kr You can see the connection status of South Korea Internet. http://www.krnic.net/english/net/net.html Hyunseog Ryu Network Engineer/Applications Engineering Norlight Telecommunications

1 0

AS3254/Lucky.net contact details
by Ryan O`Connell 27 Oct '99

27 Oct '99

Hi, (Disclaimer: I know this isn't the ideal forum, but some people just don't keep ARIN/RIPE contact details up to date) Does anyone have reliable, English-speaking contact details for AS3254/Lucky.net? I'm trying to contact them regarding malicious activity ("Hackers" to misuse the term) but I'm not getting any response to E-Mails. Thanks. --- Ryan O'Connell - On:Line Finance IT Department - <roconnell(a)olf.co.uk> Direct Voice Line: 01932 704320 Fax: 0870 242 2201 The gold road's sure a long road, winds on through the hills for fifteen days The pack on my back is aching, the straps seem to cut me like a knife I'm standing alone, I'm watching you all, I'm seeing you sinking I'm standing alone, You're weighing the gold, I'm watching you sinking

1 0

Questions about the new RADB Maintainer Fee (FAQ available)
by Craig Labovitz 27 Oct '99

27 Oct '99

Merit has received a substantial number of questions about the new RADB fee structure. A FAQ which addresses the most common of these questions is now available -- please see: http://www.radb.net/faq.html - Craig -- Craig Labovitz labovit(a)merit.edu Merit Network, Inc. http://www.merit.edu/~labovit 4251 Plymouth Road, Suite C. (734) 764-0252 (office) Ann Arbor, MI 48105-2785 (734) 647-3185 (fax)

1 0

Re: Traffic engineering tools
by Andrew Bender 26 Oct '99

26 Oct '99

> From tony1(a)home.net Tue Oct 26 05:39:16 1999 > Date: Mon, 25 Oct 1999 22:13:35 -0700 > From: Tony Li <tony1(a)home.net> > To: Alex P. Rudnev <alex(a)virgin.relcom.eu.net> > Cc: Vadim Antonov <avg(a)kotovnik.com>, abender(a)tns-inc.com, akyol(a)pluris.com, > nanog(a)merit.edu > Subject: Re: Traffic engineering tools > > > Alex, > > You are absolutely correct. A critically damped, dynamic traffic engineering system would provide benefits above and beyond that which can be derived in a static system. > > However, the dynamic system is non-trivial to construct. As has been shown with routing protocols that react to dynamic changes, it is very easy to underdamp the system, with catastrophic results. > > I certainly believe that such dynamic systems are possible, and certainly folks with enough > background in control theory could contribute wonderfully here. However, the state of the art > isn't quite there yet. Sigh. > > "And that's the way it is..." > - Walter Cronkite Hear, hear! Beside simply solving the static minimization problem, decentralized computation, and consideration of disjoint restoration paths are what I see to be necessary prerequisites ( and arguably quite "interesting" ones ) for the realization of dynamic TE. Evading these is something that we seem to have succeeded at, as engineers. As "easy" as it may be to prove the computational complexity of a problem, I find offense instead in equating such a result with a decisive judgement on practical tractability. I agree with Mr. Li that this is an approachable domain, although many of its challenges remain areas of active interest. The design of contemporary network elements suggests the unfortunate level of attention this topic receives. Despite impressive improvements in datapath, equipment control planes still seem to be sized / designed for maintenance of traditional topologies with established methods. 1000MIPS* integer cores are readily available in general purpose, commodity devices, and higher performance is neither impractical nor unknown. The possibilities this suggests for performance headroom of control systems should permit more serious consideration of practical solutions for dynamic TE than is observed today, dispensing with easy reasons not to implement path otimization or TE as a (semi-) automated, online function. Regards, Andrew Bender Total Network Solutions, Inc. (* Yes, this metric is an arbitrary and somewhat bogus oversimplication)

3 2