- Test - lists.nanog.org

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

Re: RADB Fees
by Dean Anderson 26 Oct '99

26 Oct '99

Oh come on. AV8 is pretty small, and I'll pay the fee. Though, I think $200 is pretty high for what is provided. I mean, its just a database entry after all. Right? Server operation at exchanges is paid for by server users at the exchanges. Right? So we pay Internic the outrageously high fee of $35 per year for domain registration... Doesn't seem that much different... --Dean Around 09:49 PM 10/25/1999 -0400, rumor has it that Majdi Abbas said: > >Owen wrote: >> While I agree with you in principal, the reality is that we live >> in a capitalist society, and governments are eliminating the socialist >> funding of these mechanisms which has allowed them to exist to date. >> If they are to continue to exist, they will require a source of >> funding. If you have an alternative that is better than user fees, >> please propose it. Otherwise, please recognize that this isn't >> an effort to nickle and dime so much as the result of multiple >> independent agencies being forced to self-fund their pieces of >> internet infrastructure as they lose their government funding. > > I don't see it as being cost recovery (although it is >certainly intended as such)...more as cost shifting. Here's >how it'll work: > > The people who will be affected will, in many cases, >either pool their resources (maintainers, in this case), or >get their upstreams to start handling their RADB entries. > > The end result? Merit will recover a lot less of >their costs than they might expect, and the larger ISPs >out there will get hit hard -- suddenly they're doing a >lot more administrative work than they used to have to. > > Smaller ISPs and people who just don't care enough >will stop using the RADB or not start in the first place >if they perceive the obstacles as outweighing the benefits-- >thus making it a less effective resource than it is today. > > Short term, because Merit hasn't been very public >about it to date, even on this mailing list (which was the >first on my list), a lot of people will be receiving bills >they're unaware of, and may or may not be able to get paid >on time -- presuming the maintainer contact was even up to >date in the first place -- so a lot of objects go away in >the database, and the internet will become a much less >happy place until things are resolved. > > I don't have an issue with the cost recovery aspects, >I just feel that this is rather short notice, and also rather >poorly timed (a lot of people are still busy with y2k issues, >it would have been better to wait until sometime next year). > > --msa > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Re: ** ANNOUNCE -- New RADB Fee Structure **
by Dean Anderson 26 Oct '99

26 Oct '99

Around 06:55 PM 10/26/1999 +0200, rumor has it that Adrian Chadd said: >VoIP is all well and good, but if you don't have an alternate method >of contacting people besides your (Vo)IP network, you have bigger issues >at hand than the RADB deleting your routing entries due to non-payment. Hehhhh. Then you have bigger issues than RADB... VOIP has quietly taken over like the phantom menace. How do you suppose 5cent long distance is getting implemented? (Using a 2 or 3 cpm VOIP network...) It might still be too early to really say "taken over". But you will be assimilated. ;-) Now, probably none of these networks are really part of the "public internet", but I'd have to wonder how they might be affected if there were some kind of severe problem in other parts of the internet... With PSTN - IP - PSTN connnectivity, the network can be private, and not interact with the rest of the Internet. We expect they would not be affected. But I'm not sure that will be true with PSTN - IP(vendor1) - IP(vendor2) - PSTN connectivity between vendors. Routing issues on the "public internet" can affect possibly affect this. P.S. If you want to see something really cool, check out dialpad.com. Upgrade to netscape 4.7/IE 5.0 first. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

RPSL Transition
by Gerald Andrew Winters 26 Oct '99

26 Oct '99

A reminder for users of the RADB database service: at 12:00:00 a.m. EDT on November 1, 1999, the whois.radb.net and auto-dbm(a)radb.net services will default to the Routing Policy Specification Language (RPSL) database. This means that whois queries to whois.radb.net after November 1 will return RPSL objects. RIPE-181 queries will still be possible after November 1 via whois queries to whois-ripe181.radb.net. However, you will need to *RECONFIGURE* your tools to explicitly query whois-ripe181.radb.net and send RIPE-181 submissions to auto-ripe181.radb.net. RIPE-181 submissions made between 11/1/1999 and 1/1/2000 will be visible on whois.radb.net as RIPE-181 objects converted to RPSL. The objects will be converted every five minutes from the whois-ripe181.radb.net database. Availability of the database in both syntax languages will ease the transition to RPSL by allowing users to view RIPE-181 objects converted to RPSL. After January 1, 2000, RIPE-181 object submissions will no longer be accepted. Here is the full transition schedule: DATE CHANGE ---- ------ 9/1/1999 RADB begins production RPSL service and enters the final stage of RPSL transition. RPSL queries are available from whois-rpsl.radb.net and submissions may be sent to auto-rpsl(a)radb.net. RIPE-181 and RPSL databases operate in parallel. whois.radb.net and auto-dbm(a)radb.net default to RIPE-181. 11/1/1999 Default whois.radb.net and auto-dbm(a)radb.net addresses change to RPSL database. RIPE-181 queries still possible via whois-ripe181.radb.net and RIPE-181 submissions still possible via email to auto-ripe181(a)radb.net. auto-ripe181(a)radb.net submissions will be auto-converted to RPSL and mirrored to the RPSL database every 5 minutes. Therefore, auto-converted RIPE-181 submissions will be visible on whois.radb.net and corresponding RPSL entries may be overwritten. 1/1/2000 RIPE-181 queries and submissions are no longer accepted and the RADB RPSL transition is complete. RADB users can query RPSL objects by issuing the following query: whois -h whois-rpsl.radb.net Objects may be submitted by sending mail to: auto-rpsl(a)radb.net Users may also use the Web-based GUI interface at: http://www.radb.net/irrj.html RPSL RFCs and Internet-Drafts are available through: http://www.ietf.org/html.charters/rps-charter.html Comments or questions about the transition are welcome; please send email to db-admin(a)radb.net. --Gerald Winters Merit IRRd Team

1 0

RE: Traffic engineering tools
by Vadim Antonov 26 Oct '99

26 Oct '99

> First of all, a multicommodity flow problem is not NP-complete > provided that the individual flows are an order of magnitude or so > smaller than the link capacities so that you can use a fluid approximation. > Moreover, you can come up with a heuristic that works pretty well. I believe > you must have heard of greedy algorithms. My friend prof. Plotkin says greedy algorithms were shown to produce horrible results in pretty trivial topologies. (He is the authority in MCF problems, btw). In any case, doing MCF computations in real-time is out of question even with simplistic approaches. Do it at a rate of 500 times a second - that's what you need to deal with real-life bursts of routing updates. > It is **so** easy to label a problem NP complete these days. It is so easy to miss pretty trivial solutions to problems deemed complicated. The goal of a scientist is to find an interesting problem, and live off it for a while. The goal of an engineer is to evade interesting problems :) In fact, Pluris boxes by the virtue of doing the load-sharing trick allow traffic to be treated exactly like liquid flow - thus making the traffic engineering problem trivial. The one-router-per-POP ideology also allows to satisfy acyclicity criteria for load-shared destination-address forwarding, making label switching and associated complexity simply unnecessary. --vadim (who believes in KISS principle)

3 2

Re: RADB Fees
by Majdi Abbas 26 Oct '99

26 Oct '99

Owen wrote: > While I agree with you in principal, the reality is that we live > in a capitalist society, and governments are eliminating the socialist > funding of these mechanisms which has allowed them to exist to date. > If they are to continue to exist, they will require a source of > funding. If you have an alternative that is better than user fees, > please propose it. Otherwise, please recognize that this isn't > an effort to nickle and dime so much as the result of multiple > independent agencies being forced to self-fund their pieces of > internet infrastructure as they lose their government funding. I don't see it as being cost recovery (although it is certainly intended as such)...more as cost shifting. Here's how it'll work: The people who will be affected will, in many cases, either pool their resources (maintainers, in this case), or get their upstreams to start handling their RADB entries. The end result? Merit will recover a lot less of their costs than they might expect, and the larger ISPs out there will get hit hard -- suddenly they're doing a lot more administrative work than they used to have to. Smaller ISPs and people who just don't care enough will stop using the RADB or not start in the first place if they perceive the obstacles as outweighing the benefits-- thus making it a less effective resource than it is today. Short term, because Merit hasn't been very public about it to date, even on this mailing list (which was the first on my list), a lot of people will be receiving bills they're unaware of, and may or may not be able to get paid on time -- presuming the maintainer contact was even up to date in the first place -- so a lot of objects go away in the database, and the internet will become a much less happy place until things are resolved. I don't have an issue with the cost recovery aspects, I just feel that this is rather short notice, and also rather poorly timed (a lot of people are still busy with y2k issues, it would have been better to wait until sometime next year). --msa

1 0