- NANOG - lists.nanog.org

Transport level multihoming
by Greg Maxwell 02 Apr '01

02 Apr '01

Has anyone here had any discussion about the potential for transport level multihoming (like SCTP) to replace the current use of globally advertised multihoming on the Internet? If the transport pushes multihoming to the end node and IP layer multihoming not being propagated beyond direct peers. It would seem that such a system could significantly further the scalability of the Internet, while increasing the level of flexibility of multihoming (i.e. if the transport allows adding address to a connection in progress, this would facilitate mobility).

1 1

RE: Routing System Scaling - Disaster Looming, but Medium-Term Fi xes Known
by Roeland Meyer 02 Apr '01

02 Apr '01

> From: smd(a)clock.org [mailto:smd@clock.org] > Sent: Monday, April 02, 2001 5:59 AM > So, there are several Deaths of the Internet which are possible: > > -- it's too expensive to keep up with growth, so utilization > -- we blow up on one of the scaling axes > -- too much dynamism: poof, our memory isn't > -- we blow up because while we can handle some of the > -- inefficient/broken routing: we don't have the power One observation here, PC133 RAM is getting ever cheaper, as are CPUs. If routers were designed around commoditized components their COGm would be lower. Of course, the router vendors would no longer be able to get the premium prices for their boxen, either. > What I wish I had finished @ Sprint: a web-based form that lets > one arrange an exception to access-list 112 for some small fee, > like $50/month/change. For your 50 bucks, you see no filtering > on one of your long prefixes for a whole month (or year or whatever). > > These days it may be that your $50/month will make your > long prefix less likely to be damped out of the routing table > for a long time, however there is scope for further innovation, > such as charging only $5 to clear your prefix out of the flap-damping > penalty box of one router. I, for one, would gladly pay for such a service. Provided that I don't have to pay it to 32 ISPs per month.

2 1

Re: Lame reverse delegation at Sprint (fwd)
by John R Levine 02 Apr '01

02 Apr '01

> I walked the tree manually <see attached>. Two problems. > > 1. SDN.IECC.COM does not answer authoritatively. Odd, it's supposed to be authoritative and it's authoritative now. Something was very strange over the weekend. In case it's not obvious, light.lightlink.com is my DNS mirror, who's also supposed to be authoritative, ivan.iecc.com is my old server I'm trying to turn off, sdn.iecc.com is the new one. > 2. In our database, you have IVAN.IECC.COM as the primary NS that we > delegate to, for 42.31.208.in-addr.arpa. In turn, IVAN delegates to > SDN.IECC.COM. For the sake of efficiency, you may want to ask your ISP to > send an e-mail to dns(a)sprint.net and ask our NOC to change this in our > database to SDN.IECC.COM. Of course, once SDN.IECC.COM is answering > authoritatively again. Thanks, will do. Regards, John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47

1 0

RE: InterNAP
by Deitrich Dave-CDD039 02 Apr '01

02 Apr '01

> They've been down around $1.50 a share for a while now... but apparently > as of today their stock is up 34%. Something I should know about InterNAP? Does anyone know why InterNAP stock is so low in the first place? I've been looking around online and I haven't found any noticeably bad press about them. We've talked with several of InterNAP's customers as part of our own evaluation and according to them InterNAP practically walks on water. I don't get it... :-( -- DAVE DEITRICH dave.deitrich(a)motorola.com

1 0

RE: Routing System Scaling - Disaster Looming, but Medium-Term Fixes Known
by smd＠clock.org 02 Apr '01

02 Apr '01

Bill - If your magical mystical OBGP stuff puts pressure on the global routing system, you can expect at some point that people stop subsidizing your use of their resources, and start filtering or damping you, or charging you real money. If your magical mystical OBGP stuff does not, then it is irrelevant to the scaling of the global routing system by virtue of having no impact on it. There is NO reason why significant site-to-site multihoming need be made visible to the global routing system, if sites are not providing global transit for one another via entities that cannot aggregate the sites behind a single prefix. That UfT and YorkU have some sort of fast direct interconnection just for exchanging traffic between themselves does not need to be known in New York or Amsterdam, or even by ONET. There is probably some opportunity for you to exploit the fact that few networks impose any kind of barrier on resource consumption at the present time. Surely, though, you would be better off looking at the reality that operators face before arguing that your "empower the edge!" ideas are truly cost-saving. Sean.

1 0

Re: Faster 'Net growth rate raises fears about routers
by Sean Donelan 02 Apr '01

02 Apr '01

On Mon, 02 April 2001, Adrian Chadd wrote: > *shakes head* people keep forgetting this. Do you guys also > think you can solve the internets problems by adding more bandwidth? The Internet has long practiced the "just-in-time," "solve-only-the-current-problem" style of network engineering. If we can solve the internet's problems for a few more years by adding more bandwidth, why do something more complex? Yeah, OSI/ISO, IPV6, ATM/MPLS etc solve several problems the Internet doesn't have yet. But until that time, gun the engine and ram the envelope. It may not be elegant, but it gets today's job done.

2 1

Routing System Scaling - Disaster Looming, but Medium-Term Fixes Known
by smd＠clock.org 02 Apr '01

02 Apr '01

It's very simple: ANYONE can build a multi-Gpps router which can handle a million or two static routes. Hell, if the Internet were completely undynamic, alot of things would be much easier. Likewise, anyone can build a 0 pps router that can handle an order of magnitude more dynamism in the global routing system than we observe today. Finally, anyone can build a multi-Gpps router that can handle heavy dynamism in a global routing table consisting of a dozen prefixes. The Internet: bigger, faster, more dynamic. Choose two. One usually sees "cheaper" as one of the terms in the "choose two" joke. In this case, it's implicit, since the total price of a large router is greater than the sum of the (increasingly expensive) cost of providing the oompf necesary to do each of these three things. So, there are several Deaths of the Internet which are possible: -- it's too expensive to keep up with growth, so utilization falls off, since nobody wants to pay the real bills -- we blow up on one of the scaling axes -- too many routes: poof, we run out of memory routers are unhappy when out of memory... (ok, more memory is cheap for static storage, but ever-faster memory seems to be a general problem) -- too much dynamism: poof, our memory isn't fast enough, or the distribution of stuff via BGP/TCP isn't fast enough, or we have no CPU cycles to generate tables fast enough our our communication among routing-process CPUs and forwarding engine isn't fast enough, etc... everyone is unhappy when it takes minutes, hours, or DAYS to see the end of blackholes/loops/other effects of incomplete convergence after a change (ok, everyone knows about route damping, yes? http://www.ripe.net/docs/ripe-210.html ) -- we blow up because while we can handle some of the technical aspects of routing system complexity, we lose on human factors -- inefficient/broken routing: we don't have the power needed to apply decent policy to the routes we learn from elsewhere, which is already seen in the form of route leakage, inadvertant transit, etc., and we don't have the skills to quickly find & fix problems that have global effect The reaction to scale driven by increasing numbers of ever-longer prefixes should not be a panicky turn to something radical, or sky-is-falling moaning. It has been demonstrated (by me) that there is little reachability lost when applying prefix-length filtering, or when applying progressive flap-damping (e.g., if you flap something longer than a /24, the route's gone from my tables until tomorrow). Dennis Ferguson's arguments for maximum-prefix limits from peers are also very interesting, and have gotten some testing in the real world. Ultimately the problem here is that this just makes introducing ever-longer prefixes harder, but does not expose a real cost to someone who is thinking of doing this. If various people, or someone sufficiently large, ever gets around to implementing the following idea, I think people may be more inclined to renumber and/or be aggregated, rather than try to introduce "exception routes" into the global routing system. What I wish I had finished @ Sprint: a web-based form that lets one arrange an exception to access-list 112 for some small fee, like $50/month/change. For your 50 bucks, you see no filtering on one of your long prefixes for a whole month (or year or whatever). These days it may be that your $50/month will make your long prefix less likely to be damped out of the routing table for a long time, however there is scope for further innovation, such as charging only $5 to clear your prefix out of the flap-damping penalty box of one router. This revenue stream would surely pay for alot of the costs of upgrading routers with more memory, faster CPUs, more CPUs, faster memory, better code, etc. to deal with the increase in the number and dynamicism of the current Internet's global routing system. It might even fund the switchover to something better than the IDR architecture we have now. Sean.

1 0

Re: outages in Toronto Canada (other places?)
by Sean Donelan 02 Apr '01

02 Apr '01

On Mon, 02 April 2001, Jon Stanley wrote: > interface. Apparently some routing process got hung and had to be > restarted, the person on the other end of the phone was a little unclear > as to what the problem really was..... Has anyone spoken with someone who was a little clearer about what the problem was? Was it operator error/software bug routing problems, or an attack. It seemed unusually wide-spread, and normally UUNET is good about saying what happened. But this time everyone seems a bit fuzzy.

1 0

Sprint and peering points
by Roy 02 Apr '01

02 Apr '01

Since I am located in what PacBell thinks is a rural area, I have to contend with using multiple T1s. This forces me to play with the AS paths in order to load balance between my upstreams (Sprint and others) I have found that Sprint is prepending their AS when sending routes to many of the public exchanges (example "1239 1239 20001") in order to "shift load" to private peer connections. The result is that now my other upstreams that send out the normal "701 20001" get the brunt of the traffic from the public exchange points. Needless to say I am a bit pissed at Sprint for doing this and not telling me. I had been a fan of Sprint until this happened. Anyone else out there seeing the same problems? Any ideas on how to cure it Roy Engehausen

5 7

Re: outages in Toronto Canada (other places?)
by Sean Donelan 02 Apr '01

02 Apr '01

The UUNET status web site was last updated on Fri Mar 30 20:20:14 EST 2001 and indicates no problems on the network. The Matrix (average.miq.net) shows several drop-outs in network performance. Numerous other providers and customers sent me mail that there is a routing issue with UUNET. No word out of UUNET though.

3 3