Re: IPv6 BGP table size comparisons
On Wed, Dec 22, 2010 at 2:24 AM, Pekka Savola pek...@netcore.fi wrote: 'Maximum Prefix Length' may be an over-simplifying metric. FWIW, we're certainly not a major transit provider, but we do allow /48 in the designated PI ranges but not in the PA ranges. So the question is not necessarily just about the prefix length used because it might vary by the prefix. I know it is an over-simplification. If someone wishes to edit the page to provide more specific details about the route filtering policy for a given transit network, Wikipedia is pretty easy to edit. Hopefully they would provide a citation/link to the policy page for the NSP as well. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: Holiday Songs
Network Working Group B. Hancock Request for Comments: 1882 Network-1 Software and Technology, Inc. Category: InformationalDecember 1995 The 12-Days of Technology Before Christmas Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Discussion On the first day of Christmas, technology gave to me: A database with a broken b-tree (what the hell is a b-tree anyway?) On the second day of Christmas, technology gave to me: Two transceiver failures (CRC errors? Collisions? What is going on?) And a database with a broken b-tree (Rebuild WHAT? It's a 10GB database!) On the third day of Christmas, technology gave to me: Three French users (who, of course, think they know everything) Two transceiver failures (which are now spewing packets all over the net) And a database with a broken b-tree (Backup? What backup?) On the fourth day of Christmas, technology gave to me: Four calls for support (playing the same Christmas song over and over) Three French users (Why do they like to argue so much over trivial things?) Two transceiver failures (How the hell do I know which ones they are?) And a database with a broken b-tree (Pointer error? What's a pointer error?) On the fifth day of Christmas, technology gave to me: Five golden SCSI contacts (Of course they're better than silver!) Four support calls (Ever notice how time stands still when on hold? Three French users (No, we don't have footpedals on PC's. Why do you ask?) Two transceiver failures (If I knew which ones were bad, I would know which ones to fix!) And a database with a broken b-tree (Not till next week? Are you nuts?!?!) On the sixth day of Christmas, technology gave to me: Six games a-playing (On the production network, of course!) Five golden SCSI contacts (What do you mean not terminated!) Four support calls (No, don't transfer me again - do you HEAR? Damn!) Three French users (No, you cannot scan in by putting the page to the screen...) Two transceiver failures (I can't look at the LEDs - they're in the ceiling!) And a database with a broken b-tree (Norway? That's where this was written?) On the seventh day of Christmas, technology gave to me: Seven license failures (Expired? When?) Six games a-playing (Please stop tying up the PBX to talk to each other!) Five golden SCSI contacts (What do you mean I need wide SCSI?) Four support calls (At least the Muzak is different this time...) Three French Users (Well, monsieur, there really isn't an any key, but...) Two transceiver failures (SQE? What is that? If I knew I would set it myself!) And a database with a broken b-tree (No, I really need to talk to Lars - NOW!) On the eighth day of Christmas, technology gave to me: Eight MODEMs dialing (Who bought these? They're a security violation!) Seven license failures (How many WEEKS to get a license?) Six games a-playing (What do you mean one pixel per packet on updates?!?) Five golden SCSI contacts (Fast SCSI? It's supposed to be fast, isn't it?) Four support calls (I already told them that! Don't transfer me back - DAMN!) Three French users (No, CTL-ALT-DEL is not the proper way to end a program) Two transceiver failures (What do you mean babbling transceiver?) And a database with a broken b-tree (Does anyone speak English in Oslo?) On the ninth day of Christmas, technology gave to me: Nine lady executives with attitude (She said do WHAT with the servers?) Eight MODEMs dialing (You've been downloading WHAT?) Seven license failures (We sent the P.O. two months ago!) Six games a-playing (HOW many people are doing this to the network?) Five golden SCSI contacts (What do you mean two have the same ID?) Four support calls (No, I am not at the console - I tried that already.) Three French users (No, only one floppy fits at a time? Why do you ask?) Two transceiver failures (Spare? What spare?) And a database with a broken b-tree (No, I am trying to find Lars! L-A-R-S!) On the tenth day of
FCC petition filed by some members of NANOG in regards to Comcast and ratios as a peering criteria
As previously mentioned, the following FCC petition has been filed in regards to Comcast's peering practices (one issue being ratios as a peering criteria) by a group of NANOG members: http://fjallfoss.fcc.gov/ecfs/document/view?id=7021024373 Regards, Randy
RE: Holiday Songs
Excellent :) Stephen Stack Systems Administrator - Network -Original Message- From: Paul WALL [mailto:pauldotw...@gmail.com] Sent: 22 December 2010 05:53 To: NANOG list Subject: Holiday Songs An old classic, but maybe it will help put everyone in the holiday spirit. The Twelve Days of NYIIX On the first day of Christmas, NYIIX gave to me, A BPDU from someone's spanning tree. On the second day of Christmas, NYIIX gave to me, Two forwarding loops, And a BPDU from someone's spanning tree. On the third day of Christmas, NYIIX gave to me, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the fourth day of Christmas, NYIIX gave to me, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the fifth day of Christmas, NYIIX gave to me, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the sixth day of Christmas, NYIIX gave to me, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the seventh day of Christmas, NYIIX gave to me, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the eighth day of Christmas, NYIIX gave to me, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the ninth day of Christmas, NYIIX gave to me, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the tenth day of Christmas, NYIIX gave to me, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the eleventh day of Christmas, NYIIX gave to me, Eleven OSPF hellos, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the twelfth day of Christmas, NYIIX gave to me, Twelve peers in half-duplex, Eleven OSPF hellos, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. Disclaimer link. To see it, click the link below, or copy and paste it into your browser's address line. http://www.citco.com/emaildisclaimer.htm
Re: Holiday Songs
(must delurk to say) Very nice! May I show this to family? Robert - Original Message - From: JC Dill jcdill.li...@gmail.com Cc: NANOG list nanog@nanog.org Sent: Wednesday, December 22, 2010 3:13 AM Subject: Re: Holiday Songs Network Working Group B. Hancock Request for Comments: 1882 Network-1 Software and Technology, Inc. Category: InformationalDecember 1995 The 12-Days of Technology Before Christmas Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Discussion On the first day of Christmas, technology gave to me: A database with a broken b-tree (what the hell is a b-tree anyway?) On the second day of Christmas, technology gave to me: Two transceiver failures (CRC errors? Collisions? What is going on?) And a database with a broken b-tree (Rebuild WHAT? It's a 10GB database!) On the third day of Christmas, technology gave to me: Three French users (who, of course, think they know everything) Two transceiver failures (which are now spewing packets all over the net) And a database with a broken b-tree (Backup? What backup?) On the fourth day of Christmas, technology gave to me: Four calls for support (playing the same Christmas song over and over) Three French users (Why do they like to argue so much over trivial things?) Two transceiver failures (How the hell do I know which ones they are?) And a database with a broken b-tree (Pointer error? What's a pointer error?) On the fifth day of Christmas, technology gave to me: Five golden SCSI contacts (Of course they're better than silver!) Four support calls (Ever notice how time stands still when on hold? Three French users (No, we don't have footpedals on PC's. Why do you ask?) Two transceiver failures (If I knew which ones were bad, I would know which ones to fix!) And a database with a broken b-tree (Not till next week? Are you nuts?!?!) On the sixth day of Christmas, technology gave to me: Six games a-playing (On the production network, of course!) Five golden SCSI contacts (What do you mean not terminated!) Four support calls (No, don't transfer me again - do you HEAR? Damn!) Three French users (No, you cannot scan in by putting the page to the screen...) Two transceiver failures (I can't look at the LEDs - they're in the ceiling!) And a database with a broken b-tree (Norway? That's where this was written?) On the seventh day of Christmas, technology gave to me: Seven license failures (Expired? When?) Six games a-playing (Please stop tying up the PBX to talk to each other!) Five golden SCSI contacts (What do you mean I need wide SCSI?) Four support calls (At least the Muzak is different this time...) Three French Users (Well, monsieur, there really isn't an any key, but...) Two transceiver failures (SQE? What is that? If I knew I would set it myself!) And a database with a broken b-tree (No, I really need to talk to Lars - NOW!) On the eighth day of Christmas, technology gave to me: Eight MODEMs dialing (Who bought these? They're a security violation!) Seven license failures (How many WEEKS to get a license?) Six games a-playing (What do you mean one pixel per packet on updates?!?) Five golden SCSI contacts (Fast SCSI? It's supposed to be fast, isn't it?) Four support calls (I already told them that! Don't transfer me back - DAMN!) Three French users (No, CTL-ALT-DEL is not the proper way to end a program) Two transceiver failures (What do you mean babbling transceiver?) And a database with a broken b-tree (Does anyone speak English in Oslo?) On the ninth day of Christmas, technology gave to me: Nine lady executives with attitude (She said do WHAT with the servers?) Eight MODEMs dialing (You've been downloading WHAT?) Seven license failures (We sent the P.O. two months ago!) Six games a-playing (HOW many people are doing this to the network?) Five golden
Re: IPv6 BGP table size comparisons
Hi, I love that people compare absolute numbers but have you also checked how much noise is in there? Back in the times when I was handling a /32 for someone, I created really strict filters and was shocked. The last version (really outdated these days, so don't use it, Cisco style) was here: http://sources.zabbadoz.net/ipv6/v6-prefix-filter-20080703-public.cfg People might say that it would not be helpful at all as we want IPv6 deployed but on the other hand people apply their doings of the last 10 years 1:1 to IPv6 and continue on the same mistakes which will not be helpful either. I would really love to see weekly Routing Reports for IPv6 as we have them for legacy IP rather sooner than later. /bz -- Bjoern A. Zeeb Welcome a new stage of life. ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
I can't access this page. (http://www.xbox.com)
Hi Everybody We are ISP in Japan to which IP 49/8 is allocated from JPNIC. It seems that it is set that IP that starts from 49/8 is refused on your website. (http://www.xbox.com) As APNIC has permitted us to allocate the customer IP 49/8 (Aug 2010), please remove IP 49/8 from the filtering No. list of your website. Please refer to the following for detailed information on 49/8 http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
Re: IPv6 BGP table size comparisons
On Wed, 22 Dec 2010, Bjoern A. Zeeb wrote: People might say that it would not be helpful at all as we want IPv6 deployed but on the other hand people apply their doings of the last 10 years 1:1 to IPv6 and continue on the same mistakes which will not be helpful either. Indeed... I would really love to see weekly Routing Reports for IPv6 as we have them for legacy IP rather sooner than later. This would provide statistics and might be useful from historical POV, but I fear the operational impact of published IPv4 Routing Table reports is close to zero. (E.g. 'does it help in making people stop advertising unnecessary more-specific routes?'.) I don't expect that to change. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: IPv6 BGP table size comparisons
On Dec 22, 2010, at 6:59 AM, Pekka Savola wrote: This would provide statistics and might be useful from historical POV, but I fear the operational impact of published IPv4 Routing Table reports is close to zero. (E.g. 'does it help in making people stop advertising unnecessary more-specific routes?'.) I don't expect that to change. Actually, at the last NANOG meeting there was some value in calling out one ISP. They didn't respond publicly but several folks came over and said they were going to take corrective action. - Jared
C/D[WDM]
Anyone have any opinion on a user friendly and low-to-mid-priced CWDM or DWDM system? We need to take one pair of dark fiber and get about 5-6 10G ports on both sides. This is the info that the DF provider has given us on the route: Operating Wavelength: 1310/1550nm Maximum Attenuation:0.35 dB/km for 1310 wavelength 0.25 dB/km for 1550 wavelength Any suggestions would be tremendously helpful. thanks, -Drew
Re: C/D[WDM]
This should fit the pricerange: http://www.cubeoptics.com/passive_components.php Haven't used them yet but know of one local operator that is using them and is very satisfied... -- *blap* On Wed, Dec 22, 2010 at 15:14, Drew Weaver drew.wea...@thenap.com wrote: Anyone have any opinion on a user friendly and low-to-mid-priced CWDM or DWDM system? We need to take one pair of dark fiber and get about 5-6 10G ports on both sides. This is the info that the DF provider has given us on the route: Operating Wavelength: 1310/1550nm Maximum Attenuation:0.35 dB/km for 1310 wavelength 0.25 dB/km for 1550 wavelength Any suggestions would be tremendously helpful. thanks, -Drew
Re: IPv6 BGP table size comparisons
I would really love to see weekly Routing Reports for IPv6 as we have them for legacy IP rather sooner than later. This would provide statistics and might be useful from historical POV, but I fear the operational impact of published IPv4 Routing Table reports is close to zero. (E.g. 'does it help in making people stop advertising unnecessary more-specific routes?'.) I don't expect that to change. Today, probably not much. In the past when it started, yes, a great deal. Owen
Re: TCP congestion control and large router buffers
On 12/21/2010 04:24 PM, Fred Baker wrote: On Dec 20, 2010, at 11:18 PM, Mikael Abrahamsson wrote: On Mon, 20 Dec 2010, Jim Gettys wrote: Common knowledge among whom? I'm hardly a naive Internet user. Anyone actually looking into the matter. The Cisco fair-queue command was introduced in IOS 11.0 according tohttp://www.cisco.com/en/US/docs/ios/12_2/qos/command/reference/qrfcmd1.html#wp1098249 to somewhat handle the problem. I have no idea when this was in time, but I guess early 90:ties? 1995. I know the guy that wrote the code. Meet me in a bar and we can share war stories. The technology actually helps with problems like RFC 6057 addresses pretty effectively. is a good idea, you aren't old enough to have experienced the NSFnet collapse during the 1980's (as I did). I have post-traumatic stress disorder from that experience; I'm worried about the confluence of these changes, folks. I'm happy you were there, I was under the impression that routers had large buffers back then as well? Not really. Yup, several of us were there. The common routers on the NSFNET and related networks were fuzzballs, which had 8 (count them, 8) 576 byte buffers, Cisco AGS/AGS+, and Proteon routers. The Cisco routers of the day generally had 40 buffers on each interface by default, and might have had configuration changes; I can't comment on the Proteon routers. For a 56 KBPS line, given 1504 bytes per message (1500 bytes IP+data, and four bytes of HDLC overhead), that's theoretically 8.5 seconds. But given that messages were in fact usually 576 bytes of IP data (cf fuzzballs and unix behavior for off-LAN communications) and interspersed with TCP control messages (Acks, SYNs, FINs, RST), real queue depths were more like two seconds at a bottleneck router. The question would be the impact of a sequence of routers all acting as bottlenecks. IMHO, AQM (RED or whatever) is your friend. The question is what to set min-threshold to. Kathy Nichols (Van's wife) did a lot of simulations. I don't know that the paper was ever published, but as I recall she wound up recommending something like this: line rate ms queue depth (MBPS)RED min-threshold 2 32 10 16 155 8 622 4 2,500 2 10,000 1 I don't know if you are referring to the RED in a different light paper: that was never published, though an early draft escaped and can be found on the net. RED in a different light identifies two bugs in the RED algorithm, and proposes a better algorithm that only depends on the link output bandwidth. That draft still has a bug. The (almost completed) version of the paper that never got published; Van has retrieved it from back up, and I'm trying to pry it out of Van's hands to get it converted to something we can read today (it's in FrameMaker). In the meanwhile, turn on (W)RED! For routers run by most people on this list, it's always way better than nothing, even if Van doesn't think classic RED will solve the home router bufferbloat problem. (where we have 2 orders of magnitude variation of wireless bandwidth along with highly variable workload). That's not true in the internet core. But yes, I agree that we'd all be much helped if manufacturers of both ends of all links had the common decency of introducing a WRED (with ECN marking) AQM that had 0% drop probability at 40ms and 100% drop probability at 200ms (and linear increase between). so, min-threshold=40 ms and max-threshold=200 ms. That's good on low speed links; it will actually control queue depths to an average of O(min-threshold) at whatever value you set it to. The problem with 40 ms is that it interacts poorly with some applications, notably voice and video. It also doesn't match well to published studies like http://www.pittsburgh.intel-research.net/~kpapagia/papers/p2pdelay-analysis.pdf. In that study, a min-threshold of 40 ms would have cut in only on six a-few-second events in the course of a five hour sample. If 40 ms is on the order of magnitude of a typical RTT, it suggests that you could still have multiple retransmissions from the same session in the same queue. A good photo of buffer bloat is at ftp://ftpeng.cisco.com/fred/RTT/Pages/4.html ftp://ftpeng.cisco.com/fred/RTT/Pages/5.html The first is a trace I took overnight in a hotel I stayed in. Never mind the name of the hotel, it's not important. The second is the delay distribution, which is highly unusual - you expect to see delay distributions more like ftp://ftpeng.cisco.com/fred/RTT/Pages/8.html Thanks, Fred! Can I use these in the general bufferbloat talk I'm working on with attribution? It's a far better example/presentation in a graphic form than I currently have for the internet core case (where I don't even have anything other than memory of probing the hotel's ISP's network). (which actually shows two distributions -
Re: TCP congestion control and large router buffers
On Dec 22, 2010, at 8:48 AM, Jim Gettys wrote: I don't know if you are referring to the RED in a different light paper: that was never published, though an early draft escaped and can be found on the net. Precisely. RED in a different light identifies two bugs in the RED algorithm, and proposes a better algorithm that only depends on the link output bandwidth. That draft still has a bug. The (almost completed) version of the paper that never got published; Van has retrieved it from back up, and I'm trying to pry it out of Van's hands to get it converted to something we can read today (it's in FrameMaker). In the meanwhile, turn on (W)RED! For routers run by most people on this list, it's always way better than nothing, even if Van doesn't think classic RED will solve the home router bufferbloat problem. (where we have 2 orders of magnitude variation of wireless bandwidth along with highly variable workload). That's not true in the internet core. But yes, I agree that we'd all be much helped if manufacturers of both ends of all links had the common decency of introducing a WRED (with ECN marking) AQM that had 0% drop probability at 40ms and 100% drop probability at 200ms (and linear increase between). so, min-threshold=40 ms and max-threshold=200 ms. That's good on low speed links; it will actually control queue depths to an average of O(min-threshold) at whatever value you set it to. The problem with 40 ms is that it interacts poorly with some applications, notably voice and video. It also doesn't match well to published studies like http://www.pittsburgh.intel-research.net/~kpapagia/papers/p2pdelay-analysis.pdf. In that study, a min-threshold of 40 ms would have cut in only on six a-few-second events in the course of a five hour sample. If 40 ms is on the order of magnitude of a typical RTT, it suggests that you could still have multiple retransmissions from the same session in the same queue. A good photo of buffer bloat is at ftp://ftpeng.cisco.com/fred/RTT/Pages/4.html ftp://ftpeng.cisco.com/fred/RTT/Pages/5.html The first is a trace I took overnight in a hotel I stayed in. Never mind the name of the hotel, it's not important. The second is the delay distribution, which is highly unusual - you expect to see delay distributions more like ftp://ftpeng.cisco.com/fred/RTT/Pages/8.html Thanks, Fred! Can I use these in the general bufferbloat talk I'm working on with attribution? It's a far better example/presentation in a graphic form than I currently have for the internet core case (where I don't even have anything other than memory of probing the hotel's ISP's network). Yes. Do me a favor and remove the name of the hotel. They don't need the bad press. (which actually shows two distributions - the blue one is fairly normal, and the green one is a link that spends much of the day chock-a-block). My conjecture re 5.html is that the link *never* drops, and at times has as many as nine retransmissions of the same packet in it. The spikes in the graph are about a TCP RTO timeout apart. That's a truly worst case. For N-1 of the N retransmissions, it's a waste of storage space and a waste of bandwidth. AQM is your friend. Your buffer should be able to temporarily buffer as much as an RTT of traffic, which is to say that it should be large enough to ensure that if you get a big burst followed by a silent period you should be able to use the entire capacity of the link to ride it out. Your min-threshold should be at a value that makes your median queue depth relatively shallow. The numbers above are a reasonable guide, but as in all things, YMMV. Yup. AQM is our friend. And we need it in many places we hadn't realised we did (like our OS's). - Jim
COMSNETS 2011 (Call for Participation)
** Apologies if you received multiple copies of this call for participation ** ** Conference less than 2 weeks away ** COMSNETS 2011 The THIRD International Conference on COMmunication Systems and NETworks January 4-8, 2011, Bangalore, India http://www.comsnets.org Email: comsnets2...@ece.iisc.ernet.in (In Co-operation with ACM SIGMOBILE) (Technically Co-Sponsored by IEEE COMSOC) The Third International Conference on COMmunication Systems and NETworkS (COMSNETS) will be held in Bangalore, India, from 4 January 2011 to 8 January 2011. COMSNETS is a premier international conference dedicated to addressing advances in Networking and Communications Systems, and Telecommunications services. The goal of the conference is to create a world-class gathering of researchers from academia and industry, practitioners, business leaders, intellectual property experts, and venture capitalists, providing a forum for discussing cutting edge research, and directions for new innovative business and technology. The conference will include a highly selective technical program consisting of parallel tracks of submitted papers, a small set of invited papers on important and timely topics from well-known leaders in the field, and poster sessions of work in progress. Focused workshops and panel discussions will be held on emerging topics to allow for a lively exchange of ideas. International business and government leaders will be invited to share their perspectives, thus complementing the technical program. Registration site: http://www.comsnets.org/registration.html. Heavy student discounts available. We look forward to your participation. Conference Scope Internet Architecture and Protocols Network-based Applications Video Distribution (IPTV, Mobile Video, Video on Demand) Network Operations and Management Broadband and Cellular Networks (3G/4G, WiMAX/LTE) Mesh, Sensor and PAN Networks Communication Software (Cognitive Radios, DSA, SDR) Wireless Operating Systems and Mobile Platforms Peer-to-peer Networking Cognitive Radio and White Space Networking Optical Networks Network Security Cyber Security Technologies Cloud and Utility computing Storage Area Networks Next Generation Web Architectures Vehicular Networking Energy-Efficient Networking Network Science and Emergent Behavior in Socio-Technical Networks Social Networking Analysis, Middleware and Applications Networking Technologies for Smart Energy Grids Disruption/Delay Tolerant Networking Conference Highlights - Conference Inaugural Speaker: Prof. Raj Jain, Washington U. , St. Louis, USA Banquet speakers: Dr. Rajeev Rastogi, Yahoo Research, India Mr. Venkat Rajendran, Billonways Holdings Pvt. Ltd, India Keynote Speakers: Prof. Don Towsley, U. Mass Amherst, USA Dr. Partho Mishra, Cisco, India Mr. Subu Goparaju, Infosys, India Dr. Pravin Bhagwat, AirTight Networks, India Dr. Jean Bolot, Sprint, USA Mr. Michael Eisler, NetApp Inc, USA Workshops: WISARD (4, 5 Jan) NetHealth (4 Jan) IAMCOM (5 Jan) Mobile India 2011 (7 Jan) Technical Paper and Poster Sessions Ph.D Forum Panel Discussions Demos Exhibits General Co-Chairs - David B. Johnson, Rice University, USA Anurag Kumar, IISc Bangalore, India Technical Program Co-Chairs --- Jon Crowcroft, U. of Cambridge, UK D. Manjunath, IIT Bombay, India Archan Misra, Telcordia Tech., USA Steering Committee Co-Chairs Uday Desai, IIT Hyderabad, India Giridhar Mandyam, Qualcomm, USA Sanjoy Paul, Infosys, India Rajeev Shorey, NIIT University, India G. Venkatesh, SASKEN, India Panel Co-Chairs --- Aditya Akella, U. of Wisconsin, USA Venkat Padmanabhan, MSR, India Ph.D Forum Chair Bhaskaran Raman, IIT Bombay, India Publications Chair -- Varsha Apte, IIT Bombay, India Demos and Exhibits Co-Chairs Aaditeshwar Seth, IIT Delhi, India Ajay Bakre, Netapps, India Sponsorship Chair - Sudipta Maitra, Delhi, india Workshop Chairs --- Sharad Jaiswal, Alcatel-Lucent, India Ravindran Kaliappa, CUNY, USA Neelesh Mehta, IISc Bangalore, India Mobile India 2011 Co-Chairs --- Gene Landy, Ruperto-Israel Weiner, USA Rajaraghavan Setlur, SASKEN, India Sridhar Varadharajan, SASKEN, India Publicity Co-Chair -- Augustin Chaintreau, TTL, France Kameswari Chebrolu, IIT Bombay, India Song Chong, KAIST, Korea Ramana Kompella, Purdue Univ, USA Nishanth Sastry, U. of Cambridge, UK Web Co-Chairs - Santhana Krishnan, IIT Bombay, India Vinay Veerappa, SASKEN, India International Advisory Committee K. K.
RE: TCP congestion control and large router buffers
I don't know if you are referring to the RED in a different light paper: that was never published, though an early draft escaped and can be found on the net. RED in a different light identifies two bugs in the RED algorithm, and proposes a better algorithm that only depends on the link output bandwidth. That draft still has a bug. I also noticed another paper published later that references RED in a different light: http://www.icir.org/floyd/adaptivered/ Adaptive RED: An Algorithm for Increasing the Robustness of RED's Active Queue Management (postscript, PDF). Sally Floyd, Ramakrishna Gummadi, and Scott Shenker. August 1, 2001. And this one: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.1556rep=rep 1type=pdf July 15, 2002 Active Queue Management using Adaptive RED Rahul Verma, Aravind Iyer and Abhay Karandikar Abhay But it doesn't look like aRED went anywhere
DDoS Detection with netflow?
Has anyone run across any DDoS/anomoly detection applications that are based on netflow, preferable v9? I ran across a really old application called Panoptis, but it does not appear to have any recent development. Does anyone have any experience with this product or anything similar? Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 tmag...@providecommerce.commailto:tmag...@providecommerce.com provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowershttp://www.proflowers.com/ | redENVELOPEhttp://www.redenvelope.com/ | Cherry Moon Farmshttp://www.cherrymoonfarms.com/ | Shari's Berrieshttp://www.berries.com/
Skype info
Any word as to the root cause of the skype outage(s)? Tim Connolly Director of IT FareCompare 18111 Preston Rd Suite 800 Dallas, TX 75252 Email: tim.does.not.want.spam.conno...@farecompare.com Phone: +1 (972) 588-xxx Cell: +1 (214) 882- Web: www.farecompare.com Find deals from your airport | Connect with FareCompare on Facebook
Re: Skype info
On 12/22/2010 10:24 AM, Tim Connolly wrote: Any word as to the root cause of the skype outage(s)? Tim Connolly Director of IT Details are on their blog: http://bit.ly/edtjxB Essentially the supernodes clients connected to started dying, so they're setting up temporary mega-supernodes whilst the supernodes are fixed. Paul
Re: DDoS Detection with netflow?
On Wed, Dec 22, 2010 at 3:07 PM, Thomas Magill tmag...@providecommerce.com wrote: Has anyone run across any DDoS/anomoly detection applications that are based on netflow, preferable v9? I ran across a really old application called Panoptis, but it does not appear to have any recent development. Does anyone have any experience with this product or anything similar? http://lmgtfy.com/?q=ddos+detection+with+netflow+appliancel=1
Re: Skype info
On Wed, Dec 22, 2010 at 3:29 PM, Paul Graydon p...@paulgraydon.co.ukwrote: Details are on their blog: http://bit.ly/edtjxB %wget http://blogs.skype.com/ -O/dev/null --2010-12-22 20:45:36-- http://blogs.skype.com/ Resolving blogs.skype.com... 204.9.163.155 Connecting to blogs.skype.com|204.9.163.155|:80... failed: Operation timed out. ... -Jack
Re: Skype info
Skype downtime today Earlier today, we noticed that the number of people online on Skype was falling, which wasn’t typical or expected, so we began to investigate. Skype isn’t a network like a conventional phone or IM network – instead, it relies on millions of individual connections between computers and phones to keep things up and running. Some of these computers are what we call ‘supernodes’ – they act a bit like phone directories for Skype. If you want to talk to someone, and your Skype app can’t find them immediately (for example, because they’re connecting from a different location or from a different device) your computer or phone will first try to find a supernode to figure out how to reach them. Under normal circumstances, there are a large number of supernodes available. Unfortunately, today, many of them were taken offline by a problem affecting some versions of Skype. As Skype relies on being able to maintain contact with supernodes, it may appear offline for some of you. What are we doing to help? Our engineers are creating new ‘mega-supernodes’ as fast as they can, which should gradually return things to normal. This may take a few hours, and we sincerely apologise for the disruption to your conversations. Some features, like group video calling, may take longer to return to normal. Stay tuned to @skype on Twitter for the latest updates on the situation – and many thanks for your continued patience in the meantime. On 22 December 2010 15:46, Jack Carrozzo j...@crepinc.com wrote: On Wed, Dec 22, 2010 at 3:29 PM, Paul Graydon p...@paulgraydon.co.ukwrote: Details are on their blog: http://bit.ly/edtjxB %wget http://blogs.skype.com/ -O/dev/null --2010-12-22 20:45:36-- http://blogs.skype.com/ Resolving blogs.skype.com... 204.9.163.155 Connecting to blogs.skype.com|204.9.163.155|:80... failed: Operation timed out. ... -Jack
Re: C/D[WDM]
On 22.12.2010 15:31 Danijel wrote This should fit the pricerange: http://www.cubeoptics.com/passive_components.php Haven't used them yet but know of one local operator that is using them and is very satisfied... We are using a couple of CUBO's passive DWDM muxes @ DE-CIX. Work like a charm. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333 signature.asc Description: OpenPGP digital signature
Re: Skype info
Creating new mega-supernodes as fast as they can! Definitely using that in a meeting tomorrow. Cheers, -Jack On Wed, Dec 22, 2010 at 3:52 PM, Jeremy Parr jeremyp...@gmail.com wrote: Skype downtime today Earlier today, we noticed that the number of people online on Skype was falling, which wasn’t typical or expected, so we began to investigate. Skype isn’t a network like a conventional phone or IM network – instead, it relies on millions of individual connections between computers and phones to keep things up and running. Some of these computers are what we call ‘supernodes’ – they act a bit like phone directories for Skype. If you want to talk to someone, and your Skype app can’t find them immediately (for example, because they’re connecting from a different location or from a different device) your computer or phone will first try to find a supernode to figure out how to reach them. Under normal circumstances, there are a large number of supernodes available. Unfortunately, today, many of them were taken offline by a problem affecting some versions of Skype. As Skype relies on being able to maintain contact with supernodes, it may appear offline for some of you. What are we doing to help? Our engineers are creating new ‘mega-supernodes’ as fast as they can, which should gradually return things to normal. This may take a few hours, and we sincerely apologise for the disruption to your conversations. Some features, like group video calling, may take longer to return to normal. Stay tuned to @skype on Twitter for the latest updates on the situation – and many thanks for your continued patience in the meantime. On 22 December 2010 15:46, Jack Carrozzo j...@crepinc.com wrote: On Wed, Dec 22, 2010 at 3:29 PM, Paul Graydon p...@paulgraydon.co.uk wrote: Details are on their blog: http://bit.ly/edtjxB %wget http://blogs.skype.com/ -O/dev/null --2010-12-22 20:45:36-- http://blogs.skype.com/ Resolving blogs.skype.com... 204.9.163.155 Connecting to blogs.skype.com|204.9.163.155|:80... failed: Operation timed out. ... -Jack
Re: Skype info
I was actually going to say, you might as well have said it needs a new flux capacitor. Jeff On Wed, Dec 22, 2010 at 4:04 PM, Jack Carrozzo j...@crepinc.com wrote: Creating new mega-supernodes as fast as they can! Definitely using that in a meeting tomorrow. Cheers, -Jack On Wed, Dec 22, 2010 at 3:52 PM, Jeremy Parr jeremyp...@gmail.com wrote: Skype downtime today Earlier today, we noticed that the number of people online on Skype was falling, which wasn’t typical or expected, so we began to investigate. Skype isn’t a network like a conventional phone or IM network – instead, it relies on millions of individual connections between computers and phones to keep things up and running. Some of these computers are what we call ‘supernodes’ – they act a bit like phone directories for Skype. If you want to talk to someone, and your Skype app can’t find them immediately (for example, because they’re connecting from a different location or from a different device) your computer or phone will first try to find a supernode to figure out how to reach them. Under normal circumstances, there are a large number of supernodes available. Unfortunately, today, many of them were taken offline by a problem affecting some versions of Skype. As Skype relies on being able to maintain contact with supernodes, it may appear offline for some of you. What are we doing to help? Our engineers are creating new ‘mega-supernodes’ as fast as they can, which should gradually return things to normal. This may take a few hours, and we sincerely apologise for the disruption to your conversations. Some features, like group video calling, may take longer to return to normal. Stay tuned to @skype on Twitter for the latest updates on the situation – and many thanks for your continued patience in the meantime. On 22 December 2010 15:46, Jack Carrozzo j...@crepinc.com wrote: On Wed, Dec 22, 2010 at 3:29 PM, Paul Graydon p...@paulgraydon.co.uk wrote: Details are on their blog: http://bit.ly/edtjxB %wget http://blogs.skype.com/ -O/dev/null --2010-12-22 20:45:36-- http://blogs.skype.com/ Resolving blogs.skype.com... 204.9.163.155 Connecting to blogs.skype.com|204.9.163.155|:80... failed: Operation timed out. ... -Jack -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
.gov DNSSEC operational message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A KSK roll for the .gov zone will occur at the end of January, 2011. This key change is necessitated by a registry operator transition: VeriSign has been selected by the U.S. General Services Administration (GSA) to operate the domain name registry for .gov. It is important that you prepare for this key change NOW. DO NOT WAIT until late January, 2011, to take action: the changes described below should be made as soon as possible. Because .gov was signed prior to the signing of the root zone, it is reasonable to believe that many DNSSEC validators (usually part of recursive name servers) have the .gov zone's KSK statically configured as a trust anchor. Further, because automated trust anchor rollover software implementing the protocol described in RFC 5011 has not been widely available until recently, it is reasonable to believe that few validators with a statically configured .gov trust anchor would be able to understand a KSK roll using RFC 5011 semantics and update their trust anchor store automatically. VeriSign is sending this message to announce the impending .gov KSK roll so that the DNSSEC operational community will be informed of the change and has the opportunity to take the necessary steps to prepare for it. The .gov KSK roll will occur between 27 January 2011 and 31 January 2011. The rollover will not use RFC 5011 semantics because of issues surrounding the registry operator transition. The new KSK will not be published in an authenticated manner outside DNS (e.g., on an SSL-protected web page). Rather, the intended mechanism for trusting the new KSK is via the signed root zone: DS records corresponding to the new KSK are already present in the root zone. Because the root zone has had DS records corresponding to the current .gov KSK since 27 October 2010, static configuration of a trust anchor for .gov is currently no longer strictly necessary. Because there will be no non-DNS-based mechanism to authenticate subsequent .gov KSKs, configuration of the .gov KSK as a trust anchor is NOT RECOMMENDED. Take these steps NOW to prepare for the .gov KSK roll in late January 2011: 1. If your DNSSEC validators DO NOT HAVE a trust anchor for the root zone configured, CONFIGURE the root zone's KSK as a trust anchor. An authenticated version of the root zone's KSK is available at http://data.iana.org/root-anchors/. 2. If your DNSSEC validators have a trust anchor for the .gov zone configured, REMOVE the .gov zone's KSK as a trust anchor from your validator's configuration. If you follow both steps above, your DNSSEC validators should continue to validate names in .gov, but the .gov KSK will be authenticated via the signed root's KSK rather than a locally configured trust anchor. DO NOT WAIT until late January, 2011, to take these actions: the trust anchor changes described above should be made as soon as possible. If you have any questions or comments, please send email to regist...@dotgov.gov or reply to this message. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iQEVAwUBTRJqVNdGiUJktOYBAQJaHQf+OKcKsnUySDLzwdMUdjDpFhvm53iJF4RN /fWMK+5ahTqWpWgDnMi0NZij6OKCu+jUtH75Q9z4iXglyQzl5rweL4N01jV7GquV tYO18ys2lQ7w07XFP2Y8568ckYeWkDgYGwHJ4GKRMW4/cyl6YlE3Z+sxMbn/O3/G CcaTgmVtVHkVvLJfPMotaE9M4ldAlM3yMAHQspadVPrBNtzmYUBjJhjvwe1XxAok UBJLwqubSnY2qoAsXrwcHov4Z1izxMiuLIthyjoc79r11J0CYzwDNpDd2QyPD/3y 7nFHlxCIYDm9r2lnv8sbc/p+/PuM7rpzpkCUvpWY9FArZWt7h7gSfA== =+pAa -END PGP SIGNATURE-
Re: C/D[WDM]
+1 All our dwdm backbone is CubeOptics powered. We have about 30 pairs of DWDM band-spliiters and muxes. The attenuation is the lowest we have seen on all the wdm muxes we have tested. The tech guys @Cube optics are really smart. You can also ask for a specific mux if you have a want THE MUX. You can buy CubeOptics muxes your eyes closed -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 On Dec 22, 2010, at 10:03 PM, Arnold Nipper wrote: On 22.12.2010 15:31 Danijel wrote This should fit the pricerange: http://www.cubeoptics.com/passive_components.php Haven't used them yet but know of one local operator that is using them and is very satisfied... We are using a couple of CUBO's passive DWDM muxes @ DE-CIX. Work like a charm. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333
Re: C/D[WDM]
+1 on the CUBO recommendation. In addition to muxes, we've worked with them as a supplier of (Finisar) colored optics; our dealings have been extremely favorable on all fronts. -a
Re: C/D[WDM]
Anyone have any opinion on a user friendly and low-to-mid-priced CWDM or DWDM system? We need to take one pair of dark fiber and get about 5-6 10G ports on both sides. what kind of 10G ports? 10gige? if so, i do not see how the cubo stuff helps. will http://xkl.com/ do it for you (if short range)? randy
Re: Some truth about Comcast - WikiLeaks style
On 12/20/2010 3:14 PM, Dorn Hetzel wrote: Where I live, about 50 miles south of Atlanta down I-85, there is no consumer broadband at all. Satellite, Cellular, and T-1, those are my options. A mile away, there are choices, but not here. I am sure we aren't the only neighborhood in this situation, even today. I live 27 miles out of Seattle, WA and have those same limitations. - josh
RE: C/D[WDM]
Yes, sorry I should've specified 10Gig-E and I would like to avoid using CWDM/DWDM optics if possible I would just like to use regular LR optics. thanks, -Drew -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Wednesday, December 22, 2010 6:35 PM To: Drew Weaver Cc: 'nanog@nanog.org' Subject: Re: C/D[WDM] Anyone have any opinion on a user friendly and low-to-mid-priced CWDM or DWDM system? We need to take one pair of dark fiber and get about 5-6 10G ports on both sides. what kind of 10G ports? 10gige? if so, i do not see how the cubo stuff helps. will http://xkl.com/ do it for you (if short range)? randy
Re: C/D[WDM]
On 2010-12-22-19:44:31, Drew Weaver drew.wea...@thenap.com wrote: Yes, sorry I should've specified 10Gig-E and I would like to avoid using CWDM/DWDM optics if possible I would just like to use regular LR optics. The common misconception is that, just because you're not installing colored optics directly in your router, something similar doesn't live elsewhere in your system, mingled with a number of OEO conversions. Neat packaging and pretty GUI is orthogonal to cheap, and you stated both as initial requirements, so you're probably best choosing one or the other. We may differ on levels of frugality, however I can't think of any active system I'd classify as cheap; at the base, you're looking at a 2x multiplier from something assembled with cubes, however you slice it... If you find yourself stuck with SFP+ interfaces, or partners who don't grok this stuff and require a conventional LR hand-off, perhaps a 2xXFP transponder is really what you're after -- feed your mux with the colored optics, and the other end with some LR (or SR, CX4, ...). MRV has some good products in this space. HTH, -a
inquiry on using POS
Hi, there; First of all, thanks you all for your unintended and unnoticed help what I’ve got from nanog. I’m looking for a reference case of a point-to-point POS link. My potential customer asked me to configure their nodes using 40G POS interface cards. The distance of their nodes is between 10 km to 50 km. They are considering Cisco CRS for their core router. I’ve found that CRS has 2 kinds of POS card. One support only up to 2km. so, this one is out. From the datasheet, the other one can support point-to-point connection up to 80km using this DCU. Dispersion compensating unit. I’ve talked about this configuration with people and no one would recommend those kind of things. Personally, I prefer 10G Ethernet with XENPAK ZR optics. Here is what I want to know. Is there anyone who are using POS with DCUs (without DWDM or something like that) between nodes of less than 80km apart? If there, would you recommend it to others? Jinwha Chung CCIE#11776 u-Eng'g Team | u-Telecom Global Business Unit | SK Engineering Construction Co. Ltd South Korea TEL 82-2-3700-8822 FAX 82-2-3700-8999
Re: inquiry on using POS
On Thu, 23 Dec 2010, Jinwha Chung wrote: From the datasheet, the other one can support point-to-point connection up to 80km using this DCU. Dispersion compensating unit. I’ve talked about this configuration with people and no one would recommend those kind of things. There is nothing saying this won't work. I'd gladly implement this (if you by this mean the DPSK or dunobinary cards with g.709). The advantage of this is that you get FEC and can see what margin you have until the link starts to give post-FEC errors. Personally, I prefer 10G Ethernet with XENPAK ZR optics. If dark fiber is available, this is much much cheaper, but then you have to load balance and the customer traffic might not be possible to load balance properly on 4x10GE, but if it is, this is definitely a viable option. Middle ground would be the 4 port 10GE g.709 card with FEC if you really feel you need indications of error rate constantly. It's cheaper than the 40G card, but most likely more expensive than a 4 port 10GE card with ZR optics. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Post positive reviews
Is this spam? ;-] I have been doing a lot of playing with Google Places and the new HotPot user ranking/review product, and for once, you get an honest list of reviews by local people. Only Google account holders can post reviews in the by Google users section. I believe they also have to have a public profile. So, trashing is possible, but you have to be able to back it up or you might find the local community shouting you down ;-] I really is a fairly neat twist on building a new kind of Yellow Pages... --steve On Tue, Dec 14, 2010 at 11:40, Eugene Zola angelar...@gmail.com wrote: Google’s Huge Change and How it affects you. •Anyone can now post bad reviews and kill your rank. •We post good reviews and improve your rank. •We post good reviews to keep others from killing your rank. Google: Judge, Jury and Online Shopping Executioner Google rank is based on reviews of your business? Google Statement: ...in the last few days we developed an algorithmic solution which detects the merchant from the Times article along with hundreds of other merchants that, in our opinion, provide an extremely poor user experience. The algorithm we incorporated into our search rankings represents an initial solution to this issue, and Google users are now getting a better experience as a result. This means that anyone can write bad reviews about your business and lower your ranking. We knew that getting good reviews and not getting bad reviews was always important. Now it is a must to have good reviews for your business to keep the rank safe or to improve rank with Google. We post positive reviews for your company. We have the experience and ability to post hundreds of positive reviews that are all unique content and posted on unique IP addresses. wwwpostgoodreviews.com -- steve pirk refiamerica.org father... the sleeper has awakened... paul atreides - dune kexp.org member august '09
