October 1999 - Test - lists.nanog.org

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 25 Oct '99

25 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

RE: DNS and root servers
by Jeff Harper 25 Oct '99

25 Oct '99

James, We too have seen some weird stuff this morning (and last night). It seems we're getting bad info regarding certain domain entries that's redirecting to morehits.com. Is that what you're seeing? -- Jeff Harper Manager - Infrastructure Engineering & Support Network Engineering - NT/Unix Server Engineering GTE Intelligent Network Services jharper(a)gte.com -----Original Message----- From: James Smith [mailto:jsmith@dxstorm.com] Sent: Monday, October 25, 1999 9:41 AM To: NANOG Subject: DNS and root servers Has anybody noticed any problems this morning with some of the root name servers? (Particularly a.root-servers.net?) -- James Smith, CCNA Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2140 Winston Park Drive, Suite 203 Oakville, ON, CA L6H 5V5 Tel: 905-829-3389 Fax: 905-829-5692 1-877-DXSTORM (1-877-397-8676)

2 1

BGP confrederation ->Hierarchical RR migration
by André Chapuis 25 Oct '99

25 Oct '99

Hi everybody, Does someone have experience with migrating an AS from a confederation-topology to a topology with hierachical route-reflectors ? E.g. the BGP process on a router has to be killed in order to change from 65xxx to 'real AS-num'. Thanx André ------------------------------------------------------- André Chapuis Swisscom IP+ engineering +41 31 688 89 61 www.ip-plus.net --------------------------------------------------------

1 0

BGP confrederation ->Hierarchical RR migration
by André Chapuis 25 Oct '99

25 Oct '99

Hi everybody, Does someone have experience with migrating an AS from a confederation-topology to a topology with hierachical route-reflectors ? E.g. the BGP process on a router has to be killed in order to change from 65xxx to 'real AS-num'. Thanx André ------------------------------------------------------- André Chapuis Swisscom IP+ engineering +41 31 688 89 61 www.ip-plus.net --------------------------------------------------------

1 0

UUnet and CEF , was: Re: DNS and root servers
by Kai Schlichting 25 Oct '99

25 Oct '99

At 10:40 AM 10/25/99 -0400, James Smith wrote: >Has anybody noticed any problems this morning with some of the root name >servers? (Particularly a.root-servers.net?) No, but UUnet sure is funky today. Seems their load balancing with CEF is broken again (like every 3-4 weeks), and it seems to occur between EWR1 and DCA1.Alter.net routes more often than elsewhere. General symptom: machines (local or remote) in the same subnets can/cannot reach remote machines depending on whether the IP number (source or destination) is odd or even, or the path (forward or return) to remote machines is different depending, once again, on whether IP addresses are odd or even. That leaves the question: how does CEF decide which circuit to shove a packet into ? 3 ping runs from 3 separate, unloaded machines on the same subnet, with the last octet of their IP's being .6 , .3 and .5) --- www.yahoo.com ping statistics --- 55 packets transmitted, 55 packets received, 0% packet loss round-trip min/avg/max = 481.775/528.385/586.649 ms --- www.yahoo.com ping statistics --- 67 packets transmitted, 63 packets received, 5% packet loss round-trip min/avg/max = 216.211/271.548/310.969 ms --- www.yahoo.com ping statistics --- 62 packets transmitted, 62 packets received, 0% packet loss round-trip min/avg/max = 83.303/130.738/174.111 ms And the same machines (sequence preserved) pinging Netscape: Message from kai(a)saturn.speedus.com on ttyp0 at 12:16 ... --- www.netscape.com ping statistics --- 91 packets transmitted, 87 packets received, 4% packet loss round-trip min/avg/max = 11.679/23.564/55.384 ms --- www.netscape.com ping statistics --- 84 packets transmitted, 84 packets received, 0% packet loss round-trip min/avg/max = 209.768/241.706/270.967 ms --- www.netscape.com ping statistics --- 106 packets transmitted, 104 packets received, 1% packet loss round-trip min/avg/max = 1637.63/1688.41/1722.27 ms The same is true for a whole boatload of other sites (tested from a UUnet-connected site as well as a Globix-connected site), whether they are webservers with Local Director on the front end, or small 2501's tucked away under someone's staircase. Now try to explain that to a UUnet "Did you power-cycle your router? It must be your telco's problem!" Customer Service person - I won't waste my time :)

1 0