September 1997 - Test - lists.nanog.org

RE: Physical transport media
by Chris A. Icide 16 Sep '97

16 Sep '97

How about we use a ferritic material that has been permanently magnetized. Then we can line the pipes with supercooled electro- magnets to keep the magnetized BB's orientated in the correct manner. And when the boys in congress get some silly idea in thier heads, we can pull the end off of some of the pipes into the DC area and have a few .17 caliber rail guns on our hands..... Chris ---------- From: Scott Landman[SMTP:Scott_Landman@zd.com] Sent: Tuesday, September 16, 1997 1:59 PM To: michael(a)priori.net Cc: nanog(a)merit.edu Subject: Re: Physical transport media I would suggest using a material that isn't write once/read many in order to save having to dispose of all those BBs. How about plastic balls that could be recycled for use by simply melting them down and reforming them. Also, how do you suggest keeping the balls properly aligned so that the laser can read them? In a liquid, the BBs will rotate on all axis due to turbulence. How about grooves so the BBs will ride on rails? >Also, larger bandwidth facilities may be represented by volleyballs, >basketballs and in the near future, cageballs. :) I'm looking for venture capital for a new laser based technology called LTM. This stands for Liquid Transport Medium and it consists of lasers which holographically engrave datagrams on steel spheres the size of BB's which are then injected into the transport pipes in conjunction with a clear lubricant that serves as the liquid transport medium to carry the datagram spheres to their destination where the datagram is read from the spheres by another laser. The sphere may then be routed down another transport pipe, or, if it has reached its final destination then it is shunted off to a government data archive center in order to meet the new data access requirements that are before Congress. ******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************

1 0

Re: IP b/w out of NA
by Randall S. Benn 16 Sep '97

16 Sep '97

At 09:53 PM 9/11/97 +0200, you wrote: >Is there any place I can find more info about the aggregate IP b/w out of >North America? How many OC-3s to Europe and to Japan? Is there 600Mb/sec >of b/w from NA to Europe? Any help and pointers appreciated. I was recently looking for this kind of info myslef. Seems that most of the connectivity maps, etc. that I came across were a year or 2 out of date. FWIW, I have a collection of links concerning international L1, L2, and some L3 connectivity on my ISP page. By no means a complete reference, but it might give you a start. Randy Benn http://www.clark.net/pub/rbenn/isp.html

7 7

Chanukah [was Re: Hezbollah]
by Kent W. England 16 Sep '97

16 Sep '97

At 05:03 PM 14-09-97 -0400, Dorian R. Kim wrote: >... One of the >things that needs to be engineered into building and maintaining >national/international backbones is traffic accounting to an arbitrary >granularity that paves the way for better traffic engineering and >bandwidth projections. There are already ample tools to to per-prefix >matrix of traffic right now. Tying this in with good sales projections >will alleviate much of the last minute fire fighting. > >This will most likely never be 100% accurate and precise, but there is >no reason why we can't get a better handle on bandwidth forecasts. (say to >95% percentile) Dorian; I don't want to throw cold water on the value of planning and foresight, but in terms of predicting traffic patterns it has never worked on the Internet. It sounds good and that was the argument that all the mainframe networkers made to us early Internet networkers -- Why can't you tell me upfront what your bandwidth requirements are going to be? Don't you know exactly how many terminals you have and where they are and what application keystrokes are going to be pressed at any given time? How else can you guarantee response time in your network? This Internet stuff is stupid. It'll never work. Somehow with the way that HTTP/HTML caught fire and Internet-CB (aka VocalTec and CUSeeMe) took off, I would be loath to think I could project my backbone needs with any reliability based on *historical* projections. > >Furthermore, with the deployment of WDM and Internet core devices moving >closer to the transmission gear, if you have access to fiber, getting more >bandwidth may become as straightforward as using an additional wavelength >on the ADM that your router's plugged into. > >-dorian > > > This I like a lot better as a design technique. Throwing more bandwidth at the problem almost always works (unless the transport protocol is broken). Like Peter Kline said, Turn up the speed dial upon onset of congestion. Simple. Effective. Then again, creating a data architecture for the web (a problem that has been recognized, but not addressed in the last five years) would eliminate much of the backbone bandwidth demand. What would happen if -- presto -- a data architecture for the web showed up one day? A lot of backbone bandwidth would become surplus and a lot more edge bandwidth would be needed ASAP. What does that do to historical projections? --Kent

1 0

Re: Am I the bonehead or is it SprintLink?
by TWILKENS 16 Sep '97

16 Sep '97

On a full T1, whether it's terminating in a router or switch, the ckt will be engineered through a 3x1 dacs. This is just to move the ckt off the carrier DS3 and into the router or switch port. Subordinate slotting is not supported. The router or switch port would be a full T1 port. To downgrade the ckt to 256k the T1 must be muxed. A 1x0 or 3x0 dacs port must be inserted into the T1 path. The four DS0 channels would then be terminated on a channelized card, like a Cascade 9000 4-port T1 card. All of this can be pre engineered and a dacs xconnect completed at the time of cut over to activate the new configuration. Installing a new loop is a waist of everyone's time and the customers money. Maybe this is what Sprint had in mind. The customer would incur additional install charges and probably dual ckt payments for about a month. Todd ---------- > From: James P Bowlin <jpbowlin(a)attmail.com> > To: Jay R. Ashworth <jra(a)scfn.thpl.lib.fl.us> > Cc: Brian Horvitz <horvitz(a)nsa.shore.net>; Ehud Gavron <GAVRON(a)ACES.COM>; Eric Wieling <eric(a)ccti.net>; nanog(a)merit.edu > Subject: Re: Am I the bonehead or is it SprintLink? > Date: Tuesday, September 16, 1997 8:49 AM > > On Tue, Sep 16, 1997 at 01:17:03PM -0400, Brian Horvitz wrote: > >> Could be that they physically handle full and partial T1 circuits on > >> different facilities. I would imagine that Sprint brings in many circuits > >> on a large trunk so, to avoid the interruption of moving one end of the > >> circuit which could take it down for hours while the telco does their work, > >> they just install a new circuit and the customer does a cutover. > > >It could, I suppose... but it's not too likely. I presume you mean > >that they terminate Full- and Frac-T services on different routers at > >their end? Maybe, but who cares? I've done this sort of thing on Frame > >circuits, and it runs just the way he expected: you put two people on > >the circuit on the phone, they both flip the same switched at the same > >time, and your throughput changes. If they'll _upgrade_ you from Frac- > >to Full- that way, why in hell won't they downgrade you? > > Below is an excerpt from my direct reply to the original question. > > It may be a little more complicated than you think. My first question is > whether you are currently paying for M24 functionality on the T1. M24 allows > the carrier to break the T1 signal down to 24 DS0 signals. You cannot assume > that this is the case for a full T1. If M24 is available (is the T1 > terminated in the correct place on the carrier side) then your request is > fairly simple. If not, the T1 needs to be re-terminated in the correct place > on the carrier side. > > The reason that the upgrade is easier is that M24 functionality already exists > for circuits less than T1 speeds. You CANNOT assume that M24 is on a circuit > sold as a full T1 because there are additional costs incurred. One factor in > designing T1s is whether M24 will be required because more equipment will be > necessary. > > >>Is SprintLink being a bonehead or am I just totally clueless? > > While I am not impartial regarding the participants, I do believe the sales > droid should have expended more effort to understand what you wanted. > > Jim Bowlin > AT&T Network Operations > > I have never nor will I likely ever speak for AT&T. These words are mine and > only mine!

1 0

Re: Physical transport media
by Scott Landman 16 Sep '97

16 Sep '97

I would suggest using a material that isn't write once/read many in order to save having to dispose of all those BBs. How about plastic balls that could be recycled for use by simply melting them down and reforming them. Also, how do you suggest keeping the balls properly aligned so that the laser can read them? In a liquid, the BBs will rotate on all axis due to turbulence. How about grooves so the BBs will ride on rails? >Also, larger bandwidth facilities may be represented by volleyballs, >basketballs and in the near future, cageballs. :) I'm looking for venture capital for a new laser based technology called LTM. This stands for Liquid Transport Medium and it consists of lasers which holographically engrave datagrams on steel spheres the size of BB's which are then injected into the transport pipes in conjunction with a clear lubricant that serves as the liquid transport medium to carry the datagram spheres to their destination where the datagram is read from the spheres by another laser. The sphere may then be routed down another transport pipe, or, if it has reached its final destination then it is shunted off to a government data archive center in order to meet the new data access requirements that are before Congress. ******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************

1 0

Re: not rewriting next-hop, pointing default, ...
by Scott Huddle 16 Sep '97

16 Sep '97

I hate when contact numbers are disconnected. Does anyone have a good contact for MAI.net? -scott huddle@new6% whois -h rs.internic.net mai.net MAI Network Services (MAI3-DOM) 8200 Greensboro Drive Suite 1400 McLean, VA 22102 Domain Name: MAI.NET Administrative Contact, Technical Contact, Zone Contact: Bono, Vincent J. [1LT] (VB14) vbono(a)MAI.NET 703-734-8602 1-800-918-0524 (FAX) 1-703-506-1436 Record last updated on 04-Jun-96. Record created on 28-Jun-95. Database last updated on 10-Sep-97 04:58:14 EDT. Domain servers in listed order: NS1.MAI.NET 204.152.42.33 NS2.MAI.NET 204.152.42.12 The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. Randy Bush <randy(a)psg.com> wrote > > a senior engineer at a well-known provider just pointed out to us that > a weenie provider at mae-east was > o not rewriting next-hop > o sending our routes to others > o sending others' routes to us > o likely pointing default at us > > their noc phone was answered by a modem. we suspended peering with them and > wrote to their noc. we got back a snotty message. we have ceased peering > with them. > > we installed packet filters. our traffic on the east fddi dropped > noticeably. > > when the larger providers decline to peer with the smaller, there is a sad > reason. traceroute -g is your friend. > > randy >

11 23

Re: NANOG-PHYSICS (was Re: ATM (was Re: too many routes))
by Geoff Huston 16 Sep '97

16 Sep '97

At 04:14 PM 9/15/97 -0500, John A. Tamplin wrote: > why don't we just come up with wave equations for the >entire Internet? Now there, John, is a truly grand concept. Any takers? :-) Geoff

1 0

Re: need contact info
by Sean Donelan 15 Sep '97

15 Sep '97

>> Since NANOG seems to have turned into directory assistance, does anyone >> know the preferred, listed, international phone number for the MCI NOC, >> not a 1-800, or 1-888 number. Hopefully a number that will be in service >> longer than three months. All the non-1800 phone numbers our MCI sales >> person locate seem to be DID numbers to individual's voice mail or stop >> working when the person leaves MCI. > >919-677-5566 Cool, so far four non-MCI people have sent me phone numbers for MCI. The interesting thing is they each sent me a different phone number. 703-715-7056 703-715-7292 919-677-5351 919-677-5566 Anyone else care to play? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: LSR and packet filters
by Sean M. Doran 15 Sep '97

15 Sep '97

Vadim Antonov <avg(a)pluris.com> writes: > Hey, LSR is useful for all kinds of very interesting > denial of service attacks. A clever combination of LSR and > forged source addresses may make the attack virtually > untraceable. The denials-of-service are generally driven by poor implementation of networking software, much of which has been corrected. Moreover, in the case of LSR-using source-forged attacks, tracing becomes *easier* because you need only trap on LSR traffic and work backwards. What is *hard* is source-forged attacks which are in profile and option-free. > Useful for what? traceroute -g is the _only_ useful > application for LSR. Disabling LSR and adding an application > level service for tracing back would be just as useful. There are several people here who have mentioned on and off that LSR telnet is extremely handy to them. If you could send traffic using LSR and pay less severely for using the option in older routers, then I can think of several applications for sending lots of traffic with the LSR option toggled at the source. I can equally think of useful applications for SSR. > Encryption is an overkill for 99% of all applications. No argument here. :) > Disabling LSR and doing SA filtering can take care of > _most_ security problems. And it is computationally > cheap. SA filtering is more useful than disabling LSR. What does the additional disabling of LSR on top of ubiquitous source address filtering buy you really? > This will not make the network absolutely secure (there ain't > no such thing as absolute security), but it definitely will > make it _more_ secure. So will turning it all off, the ultimate in the utility vs security trade-off. > How'd you like to get a stream of nasty bogons aimed at > your router(s) and arriving from virtually all directions? > There's a number of ways to kill ciscos with pretty low-rate > streams. If I had a BFR up and running, this would make an interesting test to prove the design point of handling fully-decorated micropackets at line rate across fully half of all the interfaces in a fully-decked-out box. Talk to Peter about beating on one of his, or come back to me and BC in a couple weeks. (It would be equally interesting to beat on a fully decked out 75xx box with modern VIPs and dFIB, I guess. We both already know what happens when you even sneeze funny in the presence of an RP, although SPD is pretty cool at avoiding the "gee your router is unavailable" problem.) Sean.

2 1

Re: ATM (was Re: too many routes)
by Richard Irving 15 Sep '97

15 Sep '97

Peter Kline wrote: > > Hey Peter, Long time no see (a couple years at least)! I remember now you became a "Golden Handcuff" kid. How are you liking Cisco ? This thread has become a Holy war, I quit responding when some of our "esteemed" colleague's started resorting to "ad homonym" Arguments.( ie. ATM doesn't work 'cause your UGLY! ;{ ) But, for you.... :) The BPX has the capability to understand the advantage of multiple paths, and capitalize on them. Kind of a DEC spanning tree instead of an IEEE. (I just thought I would confuse everyone again ;) Certainly the easiest way to configure this is to simply manually load balance the PVC's based upon expectation, then it looks like: trunk or uni uni /DS3\ uni OC3-OC3-DS3-OC3->OC3 \DS3/ Now manually, this can be done on any vendor combo that interoperates. The downside, it won't be dynamic, and there is no way to ever get a PVC or SVC > 45mbs. You also need to know ahead of time what the utilization will be, and it cannot adjust. So if two SVC's burst at the same time, ooops. With ForeSight, the physical looks the same, except now the DS3's must be Trunks. However, the VC's can now be bundled or grouped, etc. This makes the path that any one connection takes dynamic, selecting one of the DS3 trunks. This is an "on the fly operation". It will adjust according to each VC's need, and each trunks load (with preference for re-using the same trunk if possible). It will also re-route to react to "real-time" requirements/bursts. So, if two vc's burst, they will retrain to different trunk paths, (if needed , of course...) auto-magically. Don't the guys on the Strat side of the shop talk to you guys ? ;) Richard ** "Real-Time" is defined, in this case, as "As soon as it notices, it will change as fast as it can" "DEC spanning tree vs IEEE is for the purpose of ANALOGY only, not a direct,exact,precise,perfect identical comparison, (Those who cannot see the forest for the tree's..., go into management! Just think, you will get to wear a tie everyday, and dress so nice that it will instantly be obvious to you that all the geeks in blue jeans are inferior. You can *then* have the sense of security that all these confusing technical terms seem to be undermining in you....;)" > > -peter

1 0