- Test - lists.nanog.org

RPSL announcement text
by Gerald Andrew Winters 09 Dec '99

09 Dec '99

A reminder for users of the RADB database service: at 12:00:00 a.m. EDT on January 1, 2000, the transition to the Routing Policy Specification Language (RPSL) database will be complete. After January 1, RIPE-181 object submissions will no longer be accepted. RIPE-181 submissions made between now and 1/1/2000 will continue to be visible on whois.radb.net as RIPE-181 objects converted to RPSL. Availability of the database in both syntax languages eases the transition to RPSL by allowing users to view RIPE-181 objects converted to RPSL. RIPE-181 queries will be possible until January 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. For more information, see: http://www.merit.edu/radb/announce.html Please send questions or comments to db-admin(a)radb.net. --Gerald Winters Merit IRRd team

6 9

Re: A call for the future. Was: Re: Verio Decides what parts ofthe internet to drop
by Dean Anderson 08 Dec '99

08 Dec '99

Around 03:09 PM 12/8/1999 -0800, rumor has it that Randy Bush said: >reality check: > >if you had 100TB of on-ASIC SRAM you would still be screwed. you can't >afford the PER-PACKET LATENCY of telco number style portability REFERRAL. > >once again: ip is a connectionless protocol. each packet is potentially a >new route. Potentially, but not really. >telcos don't mind a second or two in call setup, because it is CALL SETUP, >not 42 times a second. Call setups do not take a second or two. Call setups that traverse 50 switches take a second or two. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: A call for the future. Was: Re: Verio Decides what parts ofthe internet to drop
by Dean Anderson 08 Dec '99

08 Dec '99

Around 04:18 PM 12/8/1999 -0500, rumor has it that Vijay Gill said: > >On Wed, 8 Dec 1999, Dean Anderson wrote: > >> >ip is a connectionless protocol. before hitting the reply key, think about >> >that. >> >> I thought about it. It seems to me that a router is not presented with a >> stream of randomly addressed packets. In any time frame, there are going >> to be from 1 to many hundreds of packets between the same set of >> addresses. > >This is a major fallacy. Yes, fallacy that you can do this today with current routers. I agree. But the problem is that the existing routers are too slow. Jared says let the buyer beware. Well, if you nail the roughly current routing policies described, we run out of space in practice much sooner that we would otherwise. So the space becomes more valuable. Subnetting A's and B's is inevitable. Router technology will need to be more robust in the future. But the choice comes down to this: Do it (figure out how to do it) or run out of useful space a lot quicker than we expected to run out of actual space. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: A call for the future. Was: Re: Verio Decides what parts ofthe internet to drop
by Randy Bush 08 Dec '99

08 Dec '99

>>> Full route table size is not a problem. You can burn a hard disk as you >>> mentioned to store it. The issue is getting data in and out of the >>> processor, i.e. number of pins. Core flows are not ameneable to caching. >>> This approach will fail the first time you see a new packet and need to >>> swap from hard disk. >> Not that it would be very economical, but what are the technical >> implications of using a solid state device (such as the Quantum's >> RUSHMORE NTE series) instead of a normal hard drive? > Interesting question... even though it's significantly faster than an hard > drive, it does have some inherent bottlenecks such as a maximum number of > operations per second which might be a little stifling on a backbone core > router :) Still, I've never actually tried *that*, so don't know for sure. > > There's also latency in other areas - that leads me to think that regular > memory is still faster. Finally, it would be attached to the host system > through a bus (SCSI, whatever) that's a lot slower than the internal > memory bus. > > These kinds of devices tend to be a better fit for systems that doesn't > have extreme time limitations on processing data such as for mail spool > files, etc. reality check: if you had 100TB of on-ASIC SRAM you would still be screwed. you can't afford the PER-PACKET LATENCY of telco number style portability REFERRAL. once again: ip is a connectionless protocol. each packet is potentially a new route. telcos don't mind a second or two in call setup, because it is CALL SETUP, not 42 times a second. [ credit scott bradner for making this quite clear even to me in some ietf bar ] randy

1 0

Problems with sl-bb10-rly?
by Ryan Tucker 08 Dec '99

08 Dec '99

Greetings... Anyone else noticing problems with Sprint's sl-bb10-rly router? 4 sl-bb10-pen-6-1.sprintlink.net (144.232.9.102) 18.171 ms 12.329 ms 12.302 ms 5 sl-bb10-rly-10-1.sprintlink.net (144.232.8.153) 785.079 ms 787.017 ms 787.332 ms Another admin here noticed the same problem coming into bb10-rly from one of the NYC routers, so it doesn't look like just that pipe... An e-mail to noc(a)sprint.net this morning hasn't been responded to (not even by an autoresponder), and I haven't heard anything on NANOG, so just checking to see if anyone in NANOG land knows what's up. Thanks! -rt -- Ryan Tucker <rtucker(a)netacc.net> Unix Systems Administrator NetAccess, Inc. Phone: +1 716 756-5596 3495 Winton Place, Building E, Suite 265, Rochester NY 14623 www.netacc.net

2 2

Re[2]: RPSL announcement text
by chuck_metzger＠MERCER.COM 08 Dec '99

08 Dec '99

Please remove Chuck_Metzger(a)mercer.com from this list! He no longer works here. ____________________Reply Separator____________________ Subject: Re: RPSL announcement text Author: Sean Donelan <sean(a)donelan.com> Date: 12/8/99 10:50 AM > Hmm, who was this clueless manager who decided to do such things in the 1-th > of January. I guess the programmers over the world will be very busy during > january looking for the hidden Y2K bugs and fixing it, and why RADB decided > to add some more troubles just in this days? Why don't wait until, at least, > February? What terrible happen if this changes will be delayed a little? One way or another, the old routing description language will stop working at the end of this century. The syntax doesn't include four-digit years or a rollover of two digit years. Merit could terminate support sooner, but they can't really extend it. Although there have been several announcements about the end of life for ripe-181, and everyone should have switched by now, I'm sure someone will not update their procedures until after it breaks. Should Merit have "broken" them on December 1 instead of January 1? I don't know. I guess it goes under the saying, no good deed goes unpunished. Hopefully most of those users broke already when Merit changed the default on the servers, and have used the last couple of months to update their procedures. Of course those networks which have never used a routing database will say, Nah, Nah, I told you so. Received: from segue.merit.edu ([198.108.1.41]) by mail.mercer.com with SMTP (IMA Internet Exchange 3.13) id 0005AD6B; Wed, 8 Dec 1999 12:58:25 -0600 Received: by segue.merit.edu (Postfix) id 8FC965DDC6; Wed, 8 Dec 1999 13:56:09 -0500 (EST) Delivered-To: nanog-outgoing(a)merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1DD305DDC5; Wed, 8 Dec 1999 13:56:09 -0500 (EST) Received: from c004.sfo.cp.net (c004-h020.c004.sfo.cp.net [209.228.14.67]) by segue.merit.edu (Postfix) with SMTP id 4E8835DDBF for <nanog(a)merit.edu>; Wed, 8 Dec 1999 13:56:06 -0500 (EST) Received: (cpmta 23407 invoked from network); 8 Dec 1999 10:50:02 -0800 Date: 8 Dec 1999 10:50:02 -0800 Message-ID: <19991208185002.23406.cpmta(a)c004.sfo.cp.net> X-Sent: 8 Dec 1999 18:50:02 GMT Received: from [12.75.45.110] by mail.donelan.com with HTTP; 08 Dec 1999 10:50:02 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: nanog(a)merit.edu From: Sean Donelan <sean(a)donelan.com> X-Mailer: Web Mail 3.3 Subject: Re: RPSL announcement text Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing(a)merit.edu X-Loop: nanog

1 0

Re: Please help me...
by Hyunseog Ryu/Brookfield/Norlight 08 Dec '99

08 Dec '99

I tried that already. I can see the routing information from GTE for our network information in route-views.oregon-ix.net. But route-server.cerf.net does not show any routing information from GTE. In this situation, I'm thinking the possibility for routing problem if UUNET connection is down by accident or something like that. Hyun Kevin Nicholson <kcn(a)skycache.com> on 12/08/99 12:10:45 PM To: Hyunseog Ryu/Brookfield/Norlight <HRyu(a)norlight.com> cc: (bcc: Hyunseog Ryu/Brookfield/Norlight) Fax to: Subject: Re: Please help me... On Wed, 8 Dec 1999, Hyunseog Ryu/Brookfield/Norlight wrote: > Hi, folks > > Please help me. > I need your help. > If you have the right to access your router, > please send me the result of following command at your router. > > Show ip bgp reg 1_7260 > > Maybe it will be long. > But I need that. why not just telnet to route-server.cerf.net or route-views.oregon-ix.net and do a sh ip bgp regexp yourself. -Kevin Hyun

2 1

Re: RPSL announcement text
by Sean Donelan 08 Dec '99

08 Dec '99

> Hmm, who was this clueless manager who decided to do such things in the 1-th > of January. I guess the programmers over the world will be very busy during > january looking for the hidden Y2K bugs and fixing it, and why RADB decided > to add some more troubles just in this days? Why don't wait until, at least, > February? What terrible happen if this changes will be delayed a little? One way or another, the old routing description language will stop working at the end of this century. The syntax doesn't include four-digit years or a rollover of two digit years. Merit could terminate support sooner, but they can't really extend it. Although there have been several announcements about the end of life for ripe-181, and everyone should have switched by now, I'm sure someone will not update their procedures until after it breaks. Should Merit have "broken" them on December 1 instead of January 1? I don't know. I guess it goes under the saying, no good deed goes unpunished. Hopefully most of those users broke already when Merit changed the default on the servers, and have used the last couple of months to update their procedures. Of course those networks which have never used a routing database will say, Nah, Nah, I told you so.

1 0

Re: CNN connection
by Hyunseog Ryu/Brookfield/Norlight 08 Dec '99

08 Dec '99

Thank you for your comment. The problem is not a network down. They blocked traceroute and ping for their internal network. ;< I didn't think about that. There is no way to confirm network connection except real WWW traffic. Thank you, again. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyun Ryu Network Engineer/Applications Engineering Norlight Telecommunications Tel. +1.262.792.7965 Fax. +1-262.792.7733

1 0

CNN connection
by Hyunseog Ryu/Brookfield/Norlight 08 Dec '99

08 Dec '99

Good morning Do you know anything about CNN connection? It seems that they have some internet network problem or something like that. I couldn't reach to cnn.com. One of our customer complained about that yesterday. But it still doesn't work. I checked SPRINT, GTE, and UUNET connection also, but it was same result. Traffic was timeout at the serial port of CNN gateway. If you have some information about this, please let me know. Hyun ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyunseog Ryu Network Engineer/Applications Engineering Norlight Telecommunications, Inc. 275 North Corporate Drive Brookfield, WI 53045-5818 Tel. +1.262.792.7965 Fax. +1.262.792.7733

1 0