November 1997 - Test - lists.nanog.org

Re: PSInet - iSTAR purchase
by Chris MacFarlane 11 Nov '97

11 Nov '97

Don't forget about little old ACC! In our view this makes us the only mid sized nationwide ISP in the great white north! ACC/Internet Canada www.ican.net looks better every day! Chris MacFarlane Manager, Data Operations ACC Telecom 4162132023 cmacfarlane(a)acc.ca cjm(a)ican.net -----Original Message----- From: Michael Gibson <magibson(a)netcom.ca> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Monday, November 10, 1997 12:30 PM Subject: Re: PSInet - iSTAR purchase >The Canadian marketplace just got smaller. This and the recent hookup stuff >leave us with a handful of national ISPs. > >-----Original Message----- >From: Avi Freedman <freedman(a)netaxs.com> >To: nanog(a)merit.edu <nanog(a)merit.edu> >Date: Monday, November 10, 1997 11:21 AM >Subject: PSInet - iSTAR purchase > > >> >>Forwarded to me by a wimp who didn't want to be accused of solely >>posting trivia to NANOG: >> >>"In a surprise move calculated to restore their preeminence as the #1 >> deaggregated route leaker, PSInet (PSIX.O) has agreed to buy iSTAR >> in a stock swap." >> >>Avi >> >> >

2 1

Re: /19 addresses and redundancy
by Sean M. Doran 11 Nov '97

11 Nov '97

Phil Howard <phil(a)charon.milepost.com> writes: > Route filtering is not the end of the world. Wow. Times have changed. > You also need to make sure that the ISPs do not filter routes for parts > of their own blocks coming in from other peers. If ISP-A did such filtering, > then their own customers will find you unreachable, as well as those in ISP-C > if ISP-C sends traffic for you into ISP-A. > > I know of no ISPs doing such a thing Sprintlink did at one point. It's a really good idea to do this in general because it mitigates the disconnectivity customers assigned prefixes out of one's address blocks will suffer if and when someone accidentally(?) announces subnet of those blocks. Inbound filters can be adjusted, you know. Unfortunately the people who have inbound filters have never figured out that they should make this a service that they charge for. However, since inbound announcement filtering is a game anyone can play, I recommend people consider the implications of fee-based filter updating and how it can effect their routing whether or not they are the ones doing the inbound filtering. Connectivity = bidirectional bandwidth + bidirectional reachability. Connectivity = value. Sean.

4 3

Cleveland<->Toronto UUNET..
by jamie＠intuition.iagnet.net 11 Nov '97

11 Nov '97

I've had half a dozen tickets open with UUNET, they insist they cannot replicate. Has anyone (besides me) seen problems between Cleveland UU and UUNET-CA(Tor)? (It's sporadic but annoying) Here's one from Canada: traceroute to arpa.com (207.206.90.13), 30 hops max, 40 byte packets 1 205.150.226.1 (205.150.226.1) 2.749 ms 2.831 ms 2.243 ms 2 vl151.f000.bb1.tor2.uunet.ca (205.150.242.93) 4.974 ms 3.597 ms 2.164 ms 3 224.Hssi5-0.CR1.CLE1.Alter.Net (137.39.75.17) 348.772 ms * 346.820 ms 4 * Fddi0-0.GW1.CLE1.Alter.Net (137.39.37.101) 326.843 ms 359.163 ms 5 iag-gw.customer.ALTER.NET (157.130.96.178) 332.980 ms 336.167 ms * And back: traceroute to 205.150.226.3 (205.150.226.3), 30 hops max, 40 byte packets 1 207-206-0-32-27.gw.iagnet.net (207.206.0.33) 1.112 ms 1.088 ms 0.958 ms 2 fddi-0-0.core1.cleveland.iagnet.net (209.57.2.97) 1.010 ms 0.965 ms 1.353 ms 3 905.Hssi4-0.GW1.CLE1.ALTER.NET (157.130.96.177) 3.406 ms 2.871 ms 1.759 ms 4 Fddi0-0.CR1.CLE1.Alter.Net (137.39.37.99) 3.392 ms 3.533 ms 1.904 ms 5 119.Hssix-x.BB1.TOR2.Alter.Net (137.39.75.18) 336.981 ms 351.017 ms 316.750 ms 6 vl151.f000.bb1.tor1.uunet.ca (205.150.242.94) 308.387 ms 319.213 ms 362.870 ms -- jamie g.k. rishaw dal/efnet:gavroche __ IAGnet/CIC/netILLINOIS Backoffice DID:216.902.5455 FAX:216.623.3566 \/ 800.637.4IAGx5455 Chance favors the prepared mind.

1 0

Re: Ascend GRF
by Sean M. Doran 11 Nov '97

11 Nov '97

Phil Howard <phil(a)charon.milepost.com> writes: > I'm still waiting for T1 cards so I can put it in real service. Wow, Phil, you (and others) really like to make your vendors' lives miserable giving them really difficult to solve problems like stuffing slow interfaces into a box optimized for fast ones. That high-speed routers do not support slow interfaces is a design feature. I think, however, there is a market for "fake" BFRs (and GRFs, which are not BFRs) that are really hybrid fast/slow routers in disguise. Like a 12000 that you can put a DS3 or DS1 into, or an ersatz SSP. Router vendors take note: operators (even a really clueful one who knows who he is and is still sulking about DS3s not fitting into the 12000) will pay for the VW BUG engine and frame under a Rolls Royce body, just so long as the hood ornament looks good enough to fool their friends and it works under their real traffic load. --:) Sean.

1 0

Re: New MAE-EAST
by Sean M. Doran 11 Nov '97

11 Nov '97

"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: > At the risk of litigation, Kent makes a good point here: how much of > the problems we see are engineering based, and how much are (let's say > it softly: political? A great deal of the Internet's evolution has been affected in the past by a number of strong personalities, each of whom had her or his own set of political beliefs. There is probably no aspect of the Internet which is untouched by this observation. To some extent ALL of the problems at MAE-EAST and MAE-WEST are political, which is unsurprising, as they were both born out of politics. The first was created as a somewhat practical, somewhat political action against unfair ENSS access terms, the second was created as a political action against bad NAP design, PAC*Bell, the ATM heads at Bellcore, and probably the NSF as an agency. The names themselves come from Andrew Partan, one of those people with strong personalities and technical acumen. MAE-EAST and MAE-WEST are exploding because they are victims of success. They completely blew the official alternatives out of the water, to the extent that ANS and the ATM NAP operators are generally seen these days as Also-Rans. Unfortunately, they are in danger of blowing themselves out of the water too, thanks to the difficulties of scaling to meet demand. The history of MAE-EAST's technical evolution is amusing. There have been enormous problems in the past which have lead to threats of complete withdrawal by the initial parties, and occasional partial withdrawals. The current trend towards using private point-to-point links is really not much more different than, for example, the SWAB (in reaction to the MAE distributed ethernet not working under load, and MFS taking a long time to figure out how to address the problem properly), except that it was better thought-out than that was, and considerably more popular. To be brutal (who, me?), I think that the people who scream "this is purely (or even primarily) political not technical!" about decisions which clearly favour an NSP's stability and technical survivability are those people who also have very strong personalities but lack the technical acumen to affect the evolution of the Internet in general. On the other hand, those people who assert that the decisions are purely technical are probably being disingenuous. You may now feel free to quote some of my messages from previous lives if you like. It would serve me right. --:) Sean.

1 0

Re: New MAE-EAST
by Sean M. Doran 11 Nov '97

11 Nov '97

"Kent W. England" <kwe(a)6SigmaNets.com> writes: > There is no point agreeing with the Big Backbone Network Engineers that the > MAEs suck. It is in their best interest that the MAEs > suck, Hm. Well, it depends on how deep you want to get into conspiracy theories, of course. If there is a way to sell normalized services over an IXP such that the costs-versus-revenue split is not significantly worse than offering normal services over non-IXP technology, then there is no reason to dislike IXPs. There is technology to offer normalized services now, and apparently it is being put to some use. How much this is thought of depends on how holistically you want to view organizational financial structure and cash flow. A facilities based telco that is at an IXP that is not operated by itself is less likely to be thrilled by the thought of relatively small Internet access fees available there in comparison to the potentially very lucrative business that can be obtained through bundling Internet access as sugar in securing a more comprehensive account. (Hi, we're a telco. Buy our long distance and use our WAN outsourcing services and we will give you nearly free Internet connectivity. -- This is difficult to do at an IXP...) On the other hand, an organization that is running a large IXP and can do so without losing money -- for instance, when they are provided with a captive and unwilling market thanks to government pressure -- probably will be very fond of them, particularly if the infrastructure being paid for by the IXP participants can be turned into an aggregation point for their own Internet service offerings (and possibly, in the case of LECs who run IXPs, bundled in with other services like inter-campus WANs or even VPN telephony). (Hi. Welcome to our ATM switch. Did you know that we can make some VCs between you and University of XYZ, not to mention that we can offer a whole range of unregulated services thanks to this wonderful new NAP technology.) The thing about Internet Engineers is even the most evil greedy bastardlike ones mostly seem to want the Internet to work. Relying on IXPs which are bursting at the seams technologically and physically seems really dangerous. That some exchanges (I note you say MAEs) suck is a side-effect of their popularity. Keeping that popularity from exposing scaling problems beyond the IXPs is an intelligent design goal, which also may have convenient financial implications. > the CIX is crippled, The CIX ceased to have any real function when ANS CO+RE captiulated. Now that Rick Adams has finally eaten Al Weis's lunch, the continued existence of the CIX is almost a joke. Sorry, Bob and John. > you aren't bugging them to plug into a high perf exchange, and > that you, the little ISP, go out of business soon. Um, interesting theory. Given some statistics on where traffic loads are and who seems to present what amount of aggregate traffic in the USA, I am not sure it's really tenable though. > THEY have private interconnects which you can't join. How do you "join" a point-to-point circuit? My position on these private interconnects is that each party is offering some degree of connectivity and that normal business negotiations on the price of those services determines who pays whom what amount, if a deal is to be made at all. This is entirely like a negotiation on pricing done between any two entities on the Internet. Peering, 102: it's exactly the same as any other deal on connectivity. (cf. Vadim Antonov's question two years and change ago, "does anyone ever actually pay list prices?") Most of these private point-to-point circuits are negotiated in circuit pairs, with each party paying for one out of every two circuits. Long discussions sometimes happen about who should pay for which of a pair of circuits and whether there should be some further consideration (financial or otherwise) even within a contractual framework that is geared to make this sort of thing straightforward. > Find a co-lo where you can cross-connect without being > robbed or build your own NAP, just don't use > DEC-designed Gigaswitches and FDDI. Use full duplex 100 > Mbps Ethernet switch or find an old Fore switch cheap. This is good advice except that there are MTU implications wrt Ethernet that need considering. Personally I am hoping that people start fixing little things like the old decision to assign low default MTUs and MSSes to remote things. Something useful to consider is that there is no difference between a properly designed router and a properly designed switch, and that given a next-hop-resolution scheme (tunnels, tag switching, you name it) a router acting as a switch (a "srouter") only needs to know about its immediate adjacencies in order for connectivity to work. Sean.

1 0

Re: moving to IPv6
by Sean M. Doran 11 Nov '97

11 Nov '97

Vadim Antonov <avg(a)pluris.com> writes: > European connectivity is particularly convoluted. You have no idea... Sean. (eyeopening experiences galore)

1 0

Re: moving to IPv6
by Sean M. Doran 11 Nov '97

11 Nov '97

"John A. Tamplin" <jat(a)traveller.com> writes: > With the larger address space of IPv6, there is the capacity for an arbitrary > number of levels in the hierarchy. "Arbitrary" is overstating it, considering that the addresses are fixed-length fields. > Obviously, making use of those levels to improve on the > inefficiency noted above will require more routes to be > propagated, so there is a tradeoff. Kleinrock and Kamoun ("Stochastic Performance Evaluation of Hierarchical Routing for Large Networks") demonstrated that the optimal number of levels in a hierarchically addressed Internetwork with k routers is ln k, and so e ln k routing entries are needed per router to provide routing with acceptable amounts of non-optimality. Consequently, a scheme which can provide for this optimal number of levels also neatly bounds the amount of routing information necessary for nearly optimal routing. A fixed address length clearly can be a scaling constraint on the number of levels that can be encoded into the address itself, and one that is too short, therefore, naturally requires an Internet to carry larger numbers of routes. (One that is too long is merely wasteful of resources). Note, however, that the important thing is that such a scalable Internetwork is _hierarchically addressed_; this constraint is necessary to make any Internetwork scale, independent of the routing protocol(s) used. > I don't think we want either a routing table contaning > one route per AS ASes are an EGPism, and the deaths of EGP and its cosmetically improved descendents are long overdue. Despite all the problems with BGP, at least with respect to addressing the problem is not in the protocol, but in the need for hierarchical routing. Sean.

1 0

Re: MCI Accepts Worldcom's Bid? ; charset=us-ascii
by Al Roethlisberger 11 Nov '97

11 Nov '97

At 05:35 PM 11/10/97 -0500, you wrote: >===== Wayne Bouchard previously wrote: ==== >> >> > Pessimist Nathan? I seems to me that it would be out of character for >> > Worldcom to integrate MCI. They didn't with MFS, ANS or UUNet. Different >> > market targets? >> > >Maybe. Well Chrysler has Dodge Caravan, Plymouth Voyage and yet >Chrysler Town and Country... :-) > >Jun > Given WorldCom's past integration history with the UUNet, along with their earlier offshoots like Gridnet; I would tend to agree that they will keep these companies functionaly disparate at least for the near future. It would consume far too much time, and far too many resources to attempt to merge these different networks. Plus, as noted by other posts, to what end would merging serve? Simple issues such as IGP scaling, different legacy platforms, and other existing operations would provide too much resistance to a seamless, immediate merger. I don't think WorldCom will risk fixing something that ain't broke. I would look for each company to compete in their own way, and work to fill a market niche just like the Mopar example above. If and when UUNet, ANS, and InternetMCI becomes UUMCIANet, it yet may not be a bad thing, as this may open the door for more competitive 'regional' backbone providers to crop back up to fill the void that WorldCom and its children will vacate as they move up the food chain. Who knows....we'll see I suppose. Al

3 2

Earlier e-mail
by william＠pacific.net.ph 10 Nov '97

10 Nov '97

Good day all! This is a follow-up on my earlier e-mail. Chase Giles was correct: it was not what we thought it was. It was a case of mailboxes being full and the system just keeps on resending error messages. :( My thanks to those who sent replies privately or via the list, like J.D. Falk, Chase Giles and Phil Howard. My sincere apologies to Myriad.net for their trouble. William

1 0