March 2006 - Test - lists.nanog.org

Re: shim6 @ NANOG (forwarded note from John Payne)
by Iljitsch van Beijnum 08 Mar '06

08 Mar '06

[Crossposted to shim6 and NANOG lists, please don't make me regret this... Replies are probably best sent to just one list for people who don't subscribe to both.] On 27-feb-2006, at 22:13, Jason Schiller (schiller(a)uu.net) wrote: > Is it the consensus of the shim6 working group that the full suite > of TE > capabilities should not be a requirement? Or is this just the > opinion of > a few vocal people? I don't think I'm going out on a limb when I say that there is consensus that we need good enough traffic engineering from the start. (Where "start" means deployment, not necessarily the publication of the first RFC.) I think basic balancing of both incoming and outgoing traffic over the available links is both assumed to be part of what we need to have and implementable without too much trouble. Push back by transit ASes is harder. This is what I mean by that: A --- B / \ X Y \ / C --- D C's link to D may be low capacity or expensive, so D would prefer it if X would send traffic to Y over another route if possible. C can make this happen in BGP by prepending its AS one or more times so X will see the following AS paths: A B Y C C C D Y All else being equal, X will choose the path over A to reach Y. The simple answer here is that if the multihomed site receives a BGP feed just like today (except that it's a read only feed) and thus makes outgoing path selection decisions just like today, transit ASes have exactly the same tools as they have today. But presumably, if shim6 takes off many smaller sites that aren't comfortable with BGP will multihome also, so this push back won't work as well anymore. Creating a new way to accomplish this result is probably possible, but not entirely non-trivial, and probably something we wouldn't want to deliver on day one. Thoughts? Another capability that would be hard to replicate with shim6 is selective announcement. Today, many transit ASes allow multihomed sites to influence the way their prefix is propagated to neighbors of the transit AS. For instance, in the picture above X may decide that the link between C and D is of low quality, and set a community on the prefix it sends to C that tells C either that it should perform AS path prepending on X's prefix ONLY towards D and not towards other neighbors of C, or even not announce the prefix at all. We would need considerable extra mechanisms to replicate this capability, and maybe it can't even be fully replicated at all. So how critical is this capability?

46 200

announcement: reporting and mitigating malicious websites and phishing
by Gadi Evron 07 Mar '06

07 Mar '06

On the public botnets mailing list, there have been quite a few "off topic" reports of Malicious Websites. Sites holding malware, malicious code, drive-by installs, phishing sites, etc. The botnets list is of high traffic while it is busy figuring itself out. We expected this might happen, and so we prepared a second list where these can be handled, along with potentially phishing, etc. Baddies on Websites. There is quite a community of sysadmins, security professionals, etc. who deal with these daily. It was nice to find the public being so effective. The new PUBLIC and OPEN mailing list where anyone can join in and report suspected malicious web sites is now open. The mailing list will serve as as place: *. Where you can discuss detection techniques. *. Where you can report the sites. *. Where all relevant groups (private or otherwise) will get your reports. *. Where the relevant ISP will be automatically notified. *. Where you can see action taken on your reports. To subscribe, go to the following page: http://www.whitestar.linuxbox.org/mailman/listinfo/phishing Otherwise, to report a malicious website/phishing PRIVATELY and reach all relevant groups, please send email to: c2report(a)isotf.org Thanks, Gadi.

1 0

Re: How to measure network quality&performance for voip&gameservers (udp packetloss, delay, jitter,...)
by Vince Hoffman 07 Mar '06

07 Mar '06

On Tue, 7 Mar 2006, Justin Church wrote: > Vince Hoffman wrote: >> >> >> >> On Tue, 7 Mar 2006, Gunther Stammwitz wrote: >> >>> >>> Hello colleages, >>> >>> I'm trying to find out how one can measure the performance or quality of a >>> network for gamers and voip-users. >>> Both applications are very sensitive to packetloss, delays or jitter since >>> they're using udp instead of tcp and are very timing critical. >>> >>> ==> Which tools (under linux) are you using in order to measure your own >>> network ore on of your upstreams in terms of "gameability" or voip-usage? >>> >>> Ordinary pings won't help since routers are regulary dropping them and >>> even >>> an end-to-end ping is not perfect since one of the hosts might be busy or >>> something like that? >>> >>> Starting your favorite online game and play on a server that is being >>> housed >>> in your own network isn't the solutions I'm looking for :-( >>> >>> Your ideas are appreciated :-) >> >> >> iperf is probably your best bet here, although it needs a client/server >> config which isnt alway practical. >> it might be worth looking at pchar >> http://www.kitchenlab.org/www/bmah/Software/pchar/ >> which is pretty in depth if damm slow ;) >> >> >> Vince >> >>> >>> >>> >>> Gunther > > I too am looking for a tool to measure qos metrics for a voip deployment. > Whatever this 'something' ends up being, it needs to be highly distributed - > colocated with endpoints, do call simulation, provide some reasonable means > of centrally collecting the results, and above all cheap, since dense > distribution is key. Does such a magical tool exist? > If you are using cisco kit you could use the saa stuff which will simulate calls and provide you with jitter data[1] and knock together a few shell scripts for data collection (or use something like cricket/mrtg) Vince [1] http://www.cisco.com/warp/public/126/saa.html > -jc >

1 0

RE: Welcome back, Ma Bell
by Berkman, Scott 06 Mar '06

06 Mar '06

Going down to three companies controlling all of the last mile copper doesn't change very much. Regardless of who owns it, there has always been only been one company to get local loop/last mile from. SBC and BellSouth (or BS as I like to call it) have never been in any direct competition. BS has almost complete control over what they like to call the Nine-states region (in terms of facilities). SBC, Verizon, and Quest also had hard regions defined. Outside of BS there may have been some competition in border regions, but everywhere I have dealt with has had little direct land-line/last-mile competition. The best things I see coming out of the merger will be the drive for improvement and innovation. BS is the only one of the RBOCs that I am aware of that has actually been fighting the idea of deploying FTTH/FTTP. BS's official policy still states that they can accomplish all of the things a FTTH network can accomplish using high speed DSL versions such as vDSL. ATT and SBC both have started building out their fiber networks, most relevantly Project Lightspeed at SBC that aims to bring FTTH and IPTV. I think (and hope...) that the merger will result in that build-out EVENTUALLY (perhaps however a long way off still) making it to the BS footprint. The new ATT will have to closely compete and follow with what Verizon does. Besides wireless, the best product Vzw has to offer to home and SOHO users is FIOS, and most of the RBOCs have realized they will need to follow suit. As far as pricing and competition, the merger does not eliminate CLECs. The larger CLECs continue to grow, and the previous RBOC related mergers all included stipulations requiring access to CO's and local copper loops. Perhaps this merger will bring more detail and regulation regarding CLEC use of ILEC facilities. That would be another huge benefit. -Scott

2 1

Re: Welcome back, Ma Bell
by Eric A. Hall 06 Mar '06

06 Mar '06

On 3/6/2006 7:17 AM, Omachonu O. Ogali wrote: > Section 271 of "The Act" prevented RBOCs from selling long distance > unless if they truly opened their networks to competitive access by > CLECs (UNE-Ps primarily Right, LD was the carrot in the MFJ > Then, AT&T and Sprint exit the long distance market. MCI Friends & > Family? Nowhere to be found. ...because as it turns out, nobody can compete when LD is ~$.03 per min (or worse, when it is $.00 with voip/skype/etc). Sure there was some effort by RBOCS to get into national LD at first but once it got down to sub-nickel rates nobody cared anymore, and even the existing market giants have long since bailed on it. Too bad their debt loads weren't tied to shrinking projections. So the use of LD as carrot was the prime failure here, and is arguably what [in]directly killed the old giants. Hoorah for regulation, which tried to pick a winner, and got it absolutely wrong. > Let me cut this very short. Local, long distance, and the newest > children: cellular and Internet, all under one umbrella, well two. Except that local service is also becoming available through non-telco providers, LD is already non-existent as a market, and POTS line deployment overall has been declining for years. Internet penetration in the US has pretty much stabilized. The telcos are supposed to just whither away? The reality of realigning markets and new technologies demands that the telcos adapt. > Competition? I guess I have cable. I certainly agree that the limited range of low-latency broadband options is a problem. There is some choice there but not much. But fear of telco might also result in another scenario: cable only. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

1 0

Welcome back, Ma Bell
by Suresh Ramasubramanian 06 Mar '06

06 Mar '06

This is from Dave Farber's list .. > Subject: Everything old is new again > From: Kevin G. Barkes > > NEWS ALERT > from The Wall Street Journal > > AT&T is planning to acquire BellSouth for roughly $65 billion. A > deal between the two could be announced as early as Monday. I somehow wonder if the old executives at Ma Bell had already worked out a timeline for resurrecting her well before she was split up .. --srs -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

8 8

Re: shim6 @ NANOG
by Iljitsch van Beijnum 06 Mar '06

06 Mar '06

On 5-mrt-2006, at 20:38, Matthew Petach wrote: > Hotmail runs shim6 so that multihomed Hotmail users can keep sending > mail even when one ISP fails, while Gmail doesn't? > The customers who can't reach gmail will call their ISP to complain > about > the Internet being broken. They're not going to call Google and > ask why > they aren't installing/configuring shim6 on 150,000+ servers. This is > observable today, and is not a matter of conjecture. People who go through the expense of adding a second ISP are likely to be a bit more clueful than that, especially when they see that Gmail doesn't work and Hotmail does. > I think the trend has been pretty clear thus far--large networks/ > large providers > have been getting PI /32 allocations in order to be able to > multihome in v6 in > the same way they multihome in v4 today. And for those > organizations that > today have multiple locations that aren't connected but still need > to talk to the > Internet, they have separate v4 allocations and separate ASNs Some of them, certainly. But others use one AS number and one prefix and break the prefix into smaller pieces that are announced from different locations. > Installing shim6 will not provide companies with the > same level of redundancy that multihoming with PI space provides in > the > IPv4 world today, In a world where most hosts are shim-capable it would. It doesn't buy you fast and painless provider switching that having your own PI block does, but that's another issue. > In case you've never had to discuss network upgrades/conversions/ > migrations > with executives before, the answer to any proposal that increases > the risk to > the company's business without clear benefits that well exceed the > added risk > is "NO". Letting business people make engineering decisions is not a good idea, just like having engineers make business decisions. If the risk is too great, just let them wait and the risk will become smaller. And that's exactly what they're doing anyway. > 2 million prefixes in a router that supports 1 million is also a non- > starter. > And in 1996, we would have said 200,000 prefixes in a router that > supports 100,000 is a non-starter. And yet here we are, with everyone > in the core holding 200,000 prefixes without complaint. > 2 million prefixes in a router that supports 1 million is a non- > starter > *today*; No, it's a non-starter ALWAYS. The only variables are whether routers of the required capacity are available and if so, how much they cost. I think the only time that routing table size wasn't a consideration when buying routers for me and my customers was a few years around 2000 when a Cisco 7200 was fast enough to handle the required amounts of traffic, supported memory to do full routing and was affordable with regard to revenues in the internet business as I knew/know it (= in the Netherlands). Before that, a C7200 was too expensive for many ISPs that I knew and these days, traffic volumes are such that you really need something with hardware support but then you either have cheap multilayer switches that can't do full routing or routers that are too expensive for small ASes. > Routing table growth is more limited by the ability of entities to get > physical links installed, obtain an AS, and learn how to spell BGP > than it is by our allocation policies. Conjecture. > Yes, someday we'll get to > 2 million prefixes, as more people learn to speak BGP, and purchasing > multiple physical links becomes cheaper. But it won't be > overnight, and > routers will continue to scale, as they have from the CIDR crisis > of the 90's > to our IPv6 non-crisis of today. There is no way of knowing that. Moore's Law certainly appeared to be in bad shape a few years back as the traditional process shrinking in the chip industry hit some walls. We're back on track now, but there's no telling what will happen in the future. IPv4 has been in operation for 25 years now. Let me be generous and assume that the switch to IPv6 happens 5 years from now. With more and more stuff connected to networks the switch to IPv7 isn't going to be faster than the one from v4 to v6, so IPv6 will have to last for at least 30 years like IPv4 before it. So we have to make certain that what we do today still works in 2041. That is a LONG time to keep doubling performance every 18 months. > Now, for the rest of us, let's move on to draft a useful allocation > strategy > that allows for PI multihoming in IPv6 in the same way companies > are able > to do so in the IPv4 world. Bad idea. > If we aren't comfortable doing that, then let's draft > up the terms of the market economy that will develop in buying and > selling IPv4 > addresses as the pool runs dry If you're happy with that as an alternative for PI in IPv6, then go right ahead. Personally, I don't like the idea of organizations who got a /8 now reaping huge benefits from that and the moment this is seriously suggested you can forget about anyone giving back address space voluntarily, but if that's what it takes, fine by me. > > I have more faith in our ability to deal with route table growth > > than I do in our ability to come up with a viable instantiation > of shim6. > Engineering based on faith is insane. Even with today's science we > have balconies falling off of appartment buildings and roofs > collapsing when it rains or snows a bit harder than usual, so a > little caution here and there isn't too much to ask for. > And engineering based on FUD is equally insane. Designing a bridge > for a two-lane country highway to support 20,000 ton loads "because > someday someone might want to drive a cavalcade of dump trucks > packed to overflowing with ozmium across it" is ridiculous, and won't > get you funding. Engineers plan for reasonable safety margins, and > then post the safe operating loads. Right. And that's why your analogy doesn't work. It's more like building a bridge that can handle 20000 tons and then it turns out people really like to live on the bridge (for some reason, good analogies are hard...). Some people then say, fine, as long as you use trailers or similar mobile homes so you can move them off the bridge when necessary. Others say: go ahead, just build houses, when the load increases we'll just reinforce the bridge. Obviously this will work for a while but at some point you'll have a complete city on the bridge and all the economic activity draws more and more new people that the reinforcement efforts can no longer support. At this point, moving off the bridge becomes incredibly painful but there's no easy way out anymore. > If you take a rational look at the ASN allocation curve, I think > it's clear who is the real FUD-monger here. We can safely give > out a PI IPv6 allocation to every ASN on the Internet, and not > worry about hitting 2 million prefixes any time in the lifespan of > our current routers. Companies that have multiple locations with > different AS's today will get a prefix for each AS at each location > in IPv6, *and the sky will not fall*. There are currently some 17k ASes in the US and 265 in China. China has about four times the inhabitants of the US. If all the world reaches the same amount of multihoming as the US that would be 300k ASes today. Between 2000 and 2004 the number of IPv4 addresses given out averaged 80 million/year. Last year it was 165 million. We simply do not have enough data points to make reasonable projections, especially not over the course of 30 years. The problem with opening a can of worms is that rarely, the worms go back into the can. We have to opportunity to start from scratch with IPv6, let's not waste this because in our hubris we think we know what's going to happen in the future even though we got it wrong so many times in the past.

1 0

a plea re: shim6
by Matt Ghali 06 Mar '06

06 Mar '06

AFAIK there is no deployed, or even working shim6 code. As such, it is not an operational issue by any stretch of the imagination. There are a number of more apropriate mailing lists for discussion of issues surrounding the design and operation of shim6. Coincidentally, I am not subscribed to them. Please let it go. matto --matt(a)snark.net------------------------------------------<darwin>< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke

3 2

Re: Welcome back, Ma Bell
by Fergie 06 Mar '06

06 Mar '06

An overreach? Really? I'd say that you're not paying attention. And how do you come to that conclusion? By the fact that "very little" of the original AT&T is in the current monolith? Well, given the entire 'two-tiered' money-grab-tastic issues involved, I'd say you're a little out of touch. - ferg -- "Eric A. Hall" <ehall(a)ehsco.com> wrote: On 3/5/2006 7:10 PM, Steve Sobol wrote: > Eric A. Hall wrote: > >>What are people worried about here exactly? > > The same lack of competition in telecommunications that we had in the 1980s? Well that's an overreach. And if the primary concern is consolidation then we should have blocked NYNEX and Bell Atlantic from merging back in 1997, since this deal is basically SBC + BellSouth/Cingular, which is mostly indistinguishable from the earlier one. I think people are reacting to the brand, the AT&T ghost really, since there's none of it left. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

3 2

searching for BGP table donors
by Edward B. DREGER 05 Mar '06

05 Mar '06

Greetings all, The fuss over shim6, routing table size, and long-prefix PI space has intrigued me. I've started analyzing some [simulated] FIBs and believe I may have found something interesting. In the name of statistical sampling, I'd like to analyze some other [simulated] FIBs from different BGP views. Would anyone be interested in donating "show ip bgp" output? I assume most people are familiar with script(1), but will mention it here, in passing, "just in case". Compressed via bzip2 or rzip strongly preferred; there's a reason I'm not keen to try this on public route servers. ;-) Email is fine for up to a few megabytes. If anyone feels like sending output from so many routers that even a compressed tarball exceeds that, ping me to set up an FTP drop. Network topology and size matter not. "The more the merrier" when it comes to data analysis. :-) TIA, Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

4 4