Re: Anomalies with AS13214 ?
2009/5/11 Ricardo Oliveira rvel...@cs.ucla.edu: Hi all, First, thanks for using Cyclops, and thanks for all the Cyclops users that drop me a message about this. It seems some router in AS13214 decided to originate all the prefixes and send them to AS48285 in the Caymans, all the ASPATHs are 48285 13214. The first announcement was on 2009-05-11 11:03:11 UTC and last on 2009-05-11 12:16:32 UTC, there were 266,289 prefixes leaked (they were withdrawn afterwards) It looks like AS13214 are misbehaving again... We have just started receiving cyclops alerts indicating that AS13214 is announcing our prefixes again: Alert ID: 4927389 Alert type: origin change Monitored ASN,prefix: 78.154.96.0/19 Offending attribute: 78.154.96.0/19-13214 Date: 2009-07-28 08:30:56 UTC Duration: 00:00:01 (hh:mm:ss) No. monitors: 1 (http://cyclops.cs.ucla.edu/view_monitors.html?aid=4927389) Announced prefix: 78.154.96.0/19 Announced ASPATH: 48285 13214 BGP message: http://cyclops.cs.ucla.edu/show_myalert.html?aid=4927389 I guess ROBTEX didn't implement ingress filters after the last episode... As indicated in the Cyclops alerts, only a single monitor(AS48285) in route-views4 detected this leak. I checked on other neighbors of AS13214 and they seem fine, so it seems it was only a single router issue. This incident shows the advantage of having a wide set of peers for detection, it seems Cyclops was the only tool to detect this incident. Given the amount of banks and financial institutions in the Caymans, i would otherwise have raised a red flag, but it seems this case was an unintentional misconfig by AS13214. Would appreciate any further comment on the tool, and happy cyclopying! --Ricardo the Cyclops guy http://cyclops.cs.ucla.edu On May 11, 2009, at 8:30 AM, Jay Hennigan wrote: We're getting cyclops[1] alerts that AS13214 is advertising itself as origin for all of our prefixes. Their anomaly report shows thousands of prefixes originating there. Anyone else seeing evidence of this or being affected? [1] http://cyclops.cs.ucla.edu/ -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV -- Russell Heillinghttp://perlmonkey.blogspot.com The amazing ability of the bee to adapt herself often helps the beekeeper to overcome the results of his ignorance. - Brother Adam
Re: Anomalies with AS13214 ?
On Tue, 28 Jul 2009, Russell Heilling wrote: It looks like AS13214 are misbehaving again... We have just started receiving cyclops alerts indicating that AS13214 is announcing our prefixes again: There is talk about this being a new Quagga bug redist:ing kernel routes into BGP. I'm yelling at them for not having outgoing route filters to handle the possibility after what happened last time. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Anomalies with AS13214 ?
On Tue, Jul 28, 2009 at 11:50:02AM +0100, Russell Heilling chew...@s8n.net wrote a message of 75 lines which said: No. monitors: 1 That's why it's good to use BGP alarm systems with a peer threshold. I recommend BGPmon http://bgpmon.net/ (today, I run it with a peer thershold of 1 because the problem is rare enough but I can raise it if necessary). AFAIK, Cyclops does not have this functionality.
Re: Anomalies with AS13214 ?
On 12/05/2009, at 4:47 AM, David Freedman wrote: Yeah, interesting contact name on this: person: Fredrik Neij address:DCPNetworks address:Box 161 address:SE-11479 Stockholm address:Sweden mnt-by: MNT-DCP phone: +46 707 323819 nic-hdl:FN2233-RIPE source: RIPE # Filtered Dispatch someone from IETF, that is on in Stockholm right now. Actually, Paul Jakma might be there, dispatch him if it really is a Quagga bug. -- Nathan Ward
Re: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ?
Equinix and Mega-iAdvantage are both good choices. Equinix is just standing up their peering exchange in HK, so this is something they have over Mega-I, and both can offer connectivity to HKIX. Outside of the locations above, our HK presence is also a floor in a PCCW facility, which has been good so far. I'm also not a sales person, but we could offer the capability you are looking for, though we aren't colo if you ever needed physical access to your equipment. Tom Sands Chief Network Engineer Rackspace Managed Hosting Chris McDonald wrote: Making every effort to not pimp my employer (pccw), I would say that the Equinix in HK is good and they have a decent equinix direct product (one bill to pay). If you're looking more for a managed colo, pccw owns powerbase which does that sort of thing. HKCOLO is good but space is hard to come by. On 7/24/09, George Sanders gosand1...@yahoo.com wrote: I will be expanding a small network infrastructure service (read: DNS and mail ... a few 1u and 2u servers) to Hong Kong next year. We don't have any particular customer base in Hong Kong - rather, we have customers all over southeast asia and would like to serve them better, as well as attract more SE Asia customers. I chose Hong Kong for the following reasons: - South Korea is alternately happy with / upset with Japan, and I don't want to deal with that - Japan is is alternately happy with / upset with South Korea, and I don't want to deal with that - Mainland China is out of the question, for obvious reasons - The smaller (Thailand, Vietnamese, Phillipines, etc.) countries all have their own particular issues (recent coup in Thailand, etc.) So the choice came down to Hong Kong or Singapore, and I chose Hong Kong because it seems easier to just get things done there. I realize that in the long term there is a greater risk of social paradigm shift in Hong Kong because of mainland China, but in the short run it seems that Hong Kong is more functional than Singapore. Any comments on the above thought process ? The obvious follow-up is, which datacenter ? I need a full service center that will give me rackspace and let me just plug ethernet into their switch. I am not interested in brokering my own connectivity, nor am I interested in running my own routers. I want to pay one bill to one organization and get one cable. The end. I think there are further considerations though ... I read details of one very modern, very sexy datacenter housed in a skyscraper, but my research showed me that this building has been built on land reclaimed from the sea, and there is reasonable concern that the sand underpinnings could liquify, to a degree, in a seismic event. I'd also like to be more than a few feet above sea level. Honestly, as sexy as it would be to be in a slick tower right on the bay in Central Hong Kong, I would much rather find some nondescript, one story building, miles from the coast and a few hundred feet above sea level. What recommendations might someone have ? Thank you very much for any comments or suggestions you may have. -- Sent from Gmail for mobile | mobile.google.com . Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated.
Re: Anomalies with AS13214 ?
On Tue, Jul 28, 2009 at 11:50:02AM +0100, Russell Heilling chew...@s8n.net wrote a message of 75 lines which said: I guess ROBTEX didn't implement ingress filters after the last episode... It *seems* (I do not know them in detail) that Robtex http://www.robtex.com/, AS 48285, is dedicated to measurements, not to IP transit. If so, it makes sense for them to accept everything. If I'm right, it means Cyclops was wrong to have a monitor in an AS which is not a real operator.
Re: Anomalies with AS13214 ?
Subject: Re: Anomalies with AS13214 ? Date: Wed, Jul 29, 2009 at 12:27:56AM +1200 Quoting Nathan Ward (na...@daork.net): On 12/05/2009, at 4:47 AM, David Freedman wrote: Yeah, interesting contact name on this: person: Fredrik Neij address:DCPNetworks address:Box 161 address:SE-11479 Stockholm address:Sweden mnt-by: MNT-DCP phone: +46 707 323819 nic-hdl:FN2233-RIPE source: RIPE # Filtered (yes, it is him.) Dispatch someone from IETF, that is on in Stockholm right now. Won't help. Neij is 12 time zones away. But he is aware of the problem. -- Måns Nilsson
Re: Anomalies with AS13214 ?
On Tue, Jul 28, 2009 at 11:50:02AM +0100, Russell Heilling chew...@s8n.net wrote a message of 75 lines which said: I guess ROBTEX didn't implement ingress filters after the last episode... I simply asked them and they told me that DCP (AS 13214) is simply their transit provider so they cannot put a max-prefixes or list the prefixes announced in an ACL.
Re: Anomalies with AS13214 ?
Isn't this the second time that AS13214 seemed to have made a unintentional misconfig? On Mon, May 11, 2009 at 3:05 PM, Ricardo Oliveira rvel...@cs.ucla.eduwrote: Hi all, First, thanks for using Cyclops, and thanks for all the Cyclops users that drop me a message about this. It seems some router in AS13214 decided to originate all the prefixes and send them to AS48285 in the Caymans, all the ASPATHs are 48285 13214. The first announcement was on 2009-05-11 11:03:11 UTC and last on 2009-05-11 12:16:32 UTC, there were 266,289 prefixes leaked (they were withdrawn afterwards) As indicated in the Cyclops alerts, only a single monitor(AS48285) in route-views4 detected this leak. I checked on other neighbors of AS13214 and they seem fine, so it seems it was only a single router issue. This incident shows the advantage of having a wide set of peers for detection, it seems Cyclops was the only tool to detect this incident. Given the amount of banks and financial institutions in the Caymans, i would otherwise have raised a red flag, but it seems this case was an unintentional misconfig by AS13214. Would appreciate any further comment on the tool, and happy cyclopying! --Ricardo the Cyclops guy http://cyclops.cs.ucla.edu On May 11, 2009, at 8:30 AM, Jay Hennigan wrote: We're getting cyclops[1] alerts that AS13214 is advertising itself as origin for all of our prefixes. Their anomaly report shows thousands of prefixes originating there. Anyone else seeing evidence of this or being affected? [1] http://cyclops.cs.ucla.edu/ -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV -- --sharlon
Re: Anomalies with AS13214 ?
Russell Heilling wrote: 2009/5/11 Ricardo Oliveira rvel...@cs.ucla.edu: Hi all, First, thanks for using Cyclops, and thanks for all the Cyclops users that drop me a message about this. It seems some router in AS13214 decided to originate all the prefixes and send them to AS48285 in the Caymans, all the ASPATHs are 48285 13214. The first announcement was on 2009-05-11 11:03:11 UTC and last on 2009-05-11 12:16:32 UTC, there were 266,289 prefixes leaked (they were withdrawn afterwards) It looks like AS13214 are misbehaving again... We have just started receiving cyclops alerts indicating that AS13214 is announcing our prefixes again: We are seeing the same thing for two of our prefixes: Offending attribute: 66.251.224.0/19-13214 Offending attribute: 66.146.192.0/19-48285 Pretty annoying --steve
OT: Voice Operators' Group forming
Hi NANOG, I'd like to announce the formation of a NANOG-knockoff group for voice operators, the Voice Operators' Group. Voice network operators share many of the same challenges as IP network operators; we register with registrars (CILLI, OCN, and ACNA as well as ASN and DNS), route traffic (point codes as well as IP addresses), resolve names (CNAM as well as DNS), manage reachability (to countries, LATAs and NPA/NXXs as well as to IP networks), and deal with equipment issues. NANOG has been so useful at the IP layer that it seems like a good idea to try to duplicate it a little further up the stack. For now, the group is on Yahoo: http://tech.groups.yahoo.com/group/voip_operators_group/ Of course, we're looking for a better place, name, and charter. Regards, David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
XO - a Tier 1 or not?
Trying to sort through the marketecture and salesman speak and get a definitive answer. I figure the NANOGers would be able to give me some input. Is XO Communications a Tier 1 ISP? I'd say no based on all research and googling that I've done but they seem to meet some of the criteria (some != all and therefore not Tier 1). Any help here? Thanks as always. Chuck
Re: XO - a Tier 1 or not?
On Tue, 28 Jul 2009, Charles Mills wrote: Is XO Communications a Tier 1 ISP? ... Any help here? Thanks as always. http://en.wikipedia.org/wiki/Tier_1_network -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: XO - a Tier 1 or not?
On Jul 28, 2009, at 11:18 AM, Pekka Savola wrote: On Tue, 28 Jul 2009, Charles Mills wrote: Is XO Communications a Tier 1 ISP? ... Any help here? Thanks as always. http://en.wikipedia.org/wiki/Tier_1_network Having written a good portion of that page, in the interest of full disclosure, I would like to point out some of the comments made while I was editing (and re-editing) the page. I do not _know_ XO has settlement agreements with Sprint L3. Such contracts are covered by NDA, so (supposedly) only certain people inside Sprint, L3, and XO know whether XO is paying settlements. That said, does it matter? Settlement-Based may actually have a slight benefit over Settlement Free, as links which generate revenue may get upgraded faster than links which do not. Perhaps more importantly, does Transit Free matter? A network which has two diverse transit providers is orders of magnitude less likely to be affected by bifurcation events than transit free networks. Not to mention many non-transit free networks have better quality and service, IMHO, than some transit free networks. But hey, your money, your bits, so your decision. You want to buy from XO because they are Transit Free, or not buy from them because they are not Tier One, so be it. What's that line about competitors and encouragement... ? =) -- TTFN, patrick
Re: XO - a Tier 1 or not?
On Tue, 28 Jul 2009, Charles Mills wrote: Trying to sort through the marketecture and salesman speak and get a definitive answer. I figure the NANOGers would be able to give me some input. Is XO Communications a Tier 1 ISP? Do the best of my knowledge, no. The definition of 'Tier 1' is something of a moving target based on who you ask, but the most commonly stated criteria I've seen over the years are: 1. The provider does not buy IP transit from anyone - all traffic is moved on settlement-free public or private interconnects. That's not to say that the provider doesn't buy non-IP services (IRUs, lambdas, easements, etc) from other providers on occasion. 2. The provider lives in the default-free zone, which is pretty much a re-statement of point 1. I'll leave discussions about geographical coverage out of it for now. That said, I don't think XO meets the criteria above. I'm not 100% certain, but I don't think they're totally settlement-free. Other providers like Cogent would fall into this bucket as well. However, I also wouldn't get too hung up on tiers. Many very reliable, competent, and responsive providers providers but transit to handle at least some portion of their traffic. It also depends on what sort of service you need. For example, if you need a big MPLS pipe to another country, there are a limited number of providers who can do that, so they would tend to be the big guys. However, if you just need general IP transit, your options open up quite a bit. jms
Re: XO - a Tier 1 or not?
On Tue, Jul 28, 2009 at 11:30:47AM -0400, Justin M. Streiner wrote: On Tue, 28 Jul 2009, Charles Mills wrote: [snip] Do the best of my knowledge, no. The definition of 'Tier 1' is something of a moving target based on who you ask, but the most commonly stated criteria I've seen over the years are: 1. The provider does not buy IP transit from anyone - all traffic is moved on settlement-free public or private interconnects. That's not to say that the provider doesn't buy non-IP services (IRUs, lambdas, easements, etc) from other providers on occasion. Purchasing other services is sometimes seen as a settlement, generally based upon which end of the transaction one is sitting. 2. The provider lives in the default-free zone, which is pretty much a re-statement of point 1. Running without default (using full table, default-free zone) Has nothing to do with who you pay for what. Discussion of tiers will inevitably reach topics of marketing market dominance [eg tier one in my home region for many PTTs] and generally are not any kind of useful technical metric. In fact, it can easily be argued that the networks which run without any form of contractually binding vector for their customer's traffic are more fragile than those who have one or more paths with dollars (and various levels of penalties) attached. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: XO - a Tier 1 or not?
On Tue, 28 Jul 2009, Joe Provo wrote: On Tue, Jul 28, 2009 at 11:30:47AM -0400, Justin M. Streiner wrote: 1. The provider does not buy IP transit from anyone - all traffic is moved on settlement-free public or private interconnects. That's not to say that the provider doesn't buy non-IP services (IRUs, lambdas, easements, etc) from other providers on occasion. Purchasing other services is sometimes seen as a settlement, generally based upon which end of the transaction one is sitting. Sure, that's possible. The agreements can be structured in many different ways. Since they're often covered by nondisclosure agreements, only a handful of people on either end know the full details. Many of the peering agreements I've seen either worked the cost structure on a rotating (provider A buys the first link, provider B buys the second, etc) or a split (the two providers split the costs of the links) basis. Discussions about more advanced topics like traffic levels and settlement fall-back clauses are somewhat out of scope for this thread. 2. The provider lives in the default-free zone, which is pretty much a re-statement of point 1. Running without default (using full table, default-free zone) Has nothing to do with who you pay for what. Agreed. I brought it up because it's a common (but not entirely accurate) assumption that providers who live in the DFZ are Tier 1 providers. Discussion of tiers will inevitably reach topics of marketing market dominance [eg tier one in my home region for many PTTs] and generally are not any kind of useful technical metric. In fact, it can easily be argued that the networks which run without any form of contractually binding vector for their customer's traffic are more fragile than those who have one or more paths with dollars (and various levels of penalties) attached. Agreed again, but it's something that operators will continue to deal with as long as some providers continue to play up their tier status and customers continue to attach some relevance or assumptions of performance or reliability to it. jms
RE: XO - a Tier 1 or not?
If you limit your consideration to how things look at IP and AP/AR, then the Tier-N discussion is solvable. If you care about actual physical facilities, all bets are off. Taking a tangent from the diversity concept: http://www.atis.org/ndai/ATIS_NDAI_Final_Report_2006.pdf war-story I worked at a CLEC that purchased two SS7 links, one each from two Very Big Carriers. Both wound up going through the same fiber bundle in one particular market, on which both big guys leased bandwidth from A Minor Carrier. I've never seen a VP run as fast as when that backhoe hit us in Illinois; turns out they only *look* slow. /war-story You never really know... David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -Original Message- From: Patrick W. Gilmore [mailto:patr...@ianai.net] Sent: Tuesday, July 28, 2009 8:26 AM To: NANOG list Subject: Re: XO - a Tier 1 or not? On Jul 28, 2009, at 11:18 AM, Pekka Savola wrote: On Tue, 28 Jul 2009, Charles Mills wrote: Is XO Communications a Tier 1 ISP? ... Any help here? Thanks as always. http://en.wikipedia.org/wiki/Tier_1_network Having written a good portion of that page, in the interest of full disclosure, I would like to point out some of the comments made while I was editing (and re-editing) the page. I do not _know_ XO has settlement agreements with Sprint L3. Such contracts are covered by NDA, so (supposedly) only certain people inside Sprint, L3, and XO know whether XO is paying settlements. That said, does it matter? Settlement-Based may actually have a slight benefit over Settlement Free, as links which generate revenue may get upgraded faster than links which do not. Perhaps more importantly, does Transit Free matter? A network which has two diverse transit providers is orders of magnitude less likely to be affected by bifurcation events than transit free networks. Not to mention many non-transit free networks have better quality and service, IMHO, than some transit free networks. But hey, your money, your bits, so your decision. You want to buy from XO because they are Transit Free, or not buy from them because they are not Tier One, so be it. What's that line about competitors and encouragement... ? =) -- TTFN, patrick This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Anomalies with AS13214 ?
Seeing the same thing here. Had alerts from Cyclops roll in for all 7 of our prefixes at: 2009-07-28 08:30:26, lasted 35 mins or so: Alert ID: 4910940 Alert type: origin change Monitored ASN,prefix: 174.137.112.0/20 Offending attribute: 174.137.112.0/20-13214 Date: 2009-07-28 08:30:26 UTC Duration: 00:00:01 (hh:mm:ss) --kyle On Tue, Jul 28, 2009 at 7:53 AM, sjks...@sleepycatz.com wrote: Russell Heilling wrote: 2009/5/11 Ricardo Oliveira rvel...@cs.ucla.edu: Hi all, First, thanks for using Cyclops, and thanks for all the Cyclops users that drop me a message about this. It seems some router in AS13214 decided to originate all the prefixes and send them to AS48285 in the Caymans, all the ASPATHs are 48285 13214. The first announcement was on 2009-05-11 11:03:11 UTC and last on 2009-05-11 12:16:32 UTC, there were 266,289 prefixes leaked (they were withdrawn afterwards) It looks like AS13214 are misbehaving again... We have just started receiving cyclops alerts indicating that AS13214 is announcing our prefixes again: We are seeing the same thing for two of our prefixes: Offending attribute: 66.251.224.0/19-13214 Offending attribute: 66.146.192.0/19-48285 Pretty annoying --steve
Need help with performance troubleshooting
Starting about a week ago, I've had sporadic reports of slow uploads (hundreds of kbs, has been 10s of mbs) born out by multiple speed test sites and application results and also duplicated internally. Downloads are 50Mbs as expected (OC-3 and GigE uplinks to ATT/UUNET/Level3/Sprint/Qwest, etc). It feels like the commonality is Seattle, but I haven't been able to find anything conclusive. I'm also not seeing anything interesting in my network as far as CPU, utiliation, interface errors, etc. Hopefully not DoSing myself; I'd like to get some external visibility from the other direction; can I get results against our speedtest server ( http://speedtest.easystreet.com) along with traceroute results and geographic origin of the test? Note that traceroute won't make it all the way through due to some RFC addressing and firewall rules. Thanks, Rick
Re: OT: Voice Operators' Group forming
Hiers, David wrote: Hi NANOG, I'd like to announce the formation of a NANOG-knockoff group for voice operators, the Voice Operators' Group. Very cool! :) Voice network operators share many of the same challenges as IP network operators; we register with registrars (CILLI, OCN, and ACNA as well as ASN and DNS), route traffic (point codes as well as IP addresses), resolve names (CNAM as well as DNS), manage reachability (to countries, LATAs and NPA/NXXs as well as to IP networks), and deal with equipment issues. Indeed we do! NANOG has been so useful at the IP layer that it seems like a good idea to try to duplicate it a little further up the stack. Yep. For now, the group is on Yahoo: http://tech.groups.yahoo.com/group/voip_operators_group/ Of course, we're looking for a better place, name, and charter. Might I recommend google groups, or puck.nether.org. An IPTV list was recently formed. NAVOG works for me.
Re: OT: Voice Operators' Group forming
I second the idea of google groups or some other group provider; Yahoo groups are known within many circles for having long email delays. Charles Wyble wrote: Hiers, David wrote: Hi NANOG, I'd like to announce the formation of a NANOG-knockoff group for voice operators, the Voice Operators' Group. Very cool! :) Voice network operators share many of the same challenges as IP network operators; we register with registrars (CILLI, OCN, and ACNA as well as ASN and DNS), route traffic (point codes as well as IP addresses), resolve names (CNAM as well as DNS), manage reachability (to countries, LATAs and NPA/NXXs as well as to IP networks), and deal with equipment issues. Indeed we do! NANOG has been so useful at the IP layer that it seems like a good idea to try to duplicate it a little further up the stack. Yep. For now, the group is on Yahoo: http://tech.groups.yahoo.com/group/voip_operators_group/ Of course, we're looking for a better place, name, and charter. Might I recommend google groups, or puck.nether.org. An IPTV list was recently formed. NAVOG works for me.
Re: OT: Voice Operators' Group forming
puck.nether.net. way to volunteer someone else's box :-) -j On Tue, Jul 28, 2009 at 4:37 PM, Charles Wyble char...@thewybles.comwrote: Hiers, David wrote: Hi NANOG, I'd like to announce the formation of a NANOG-knockoff group for voice operators, the Voice Operators' Group. Very cool! :) Voice network operators share many of the same challenges as IP network operators; we register with registrars (CILLI, OCN, and ACNA as well as ASN and DNS), route traffic (point codes as well as IP addresses), resolve names (CNAM as well as DNS), manage reachability (to countries, LATAs and NPA/NXXs as well as to IP networks), and deal with equipment issues. Indeed we do! NANOG has been so useful at the IP layer that it seems like a good idea to try to duplicate it a little further up the stack. Yep. For now, the group is on Yahoo: http://tech.groups.yahoo.com/group/voip_operators_group/ Of course, we're looking for a better place, name, and charter. Might I recommend google groups, or puck.nether.org. An IPTV list was recently formed. NAVOG works for me.
Re: OT: Voice Operators' Group forming
jamie wrote: puck.nether.net http://puck.nether.net. Right. That's what I meant. way to volunteer someone else's box :-) Good point. My apologies. Google groups then. :)
Re: OT: Voice Operators' Group forming
Dear Brandon; Are you planning to favor this new group with any poetry readings ? Regards Marshall On Jul 28, 2009, at 5:49 PM, Brandon Butterworth wrote: NAVOG works for me. I'd prefer Voice Operators' Group Online Network brandon
RE: OT: Voice Operators' Group forming
So has someone created the google group yet? -Original Message- From: Marshall Eubanks [mailto:t...@americafree.tv] Sent: Tuesday, July 28, 2009 3:23 PM To: Brandon Butterworth Cc: nanog@nanog.org Subject: Re: OT: Voice Operators' Group forming Dear Brandon; Are you planning to favor this new group with any poetry readings ? Regards Marshall On Jul 28, 2009, at 5:49 PM, Brandon Butterworth wrote: NAVOG works for me. I'd prefer Voice Operators' Group Online Network brandon
Re: OT: Voice Operators' Group forming
On Jul 28, 2009, at 5:16 PM, Jack Carrozzo wrote: Are you planning to favor this new group with any poetry readings ? I for one am looking forward to the haikus. a voice group forming can we cancel the echoes of bellcore e-mail Owen
Ahoy, SLA boffins!
So I've embarked on the no-doubt-futile task of trying to interpret SLAs as empirically-verifiable technical specifications, rather than as marketing blather. And there's something that I'm finding particularly puzzling: In most SLAs, there seem to be two separate guarantees proffered: one concerning network availability and one concerning packet loss. Now, if I were to put my engineer hat on, and try to _imagine_ what the difference might be, I might imagine network availability to have something to do with layer-2 link status being presented as up, while packet loss would be the percentage of packets dropped. But when I actually read SLAs, network availability is generally defined as the portion of the month that the path from the customer's local loop to the transit or peering routers was available to transmit packets. Packet loss, on the other hand, is generally defined as the portion of packets which are lost while crossing that exact same piece of network. Now, what am I missing here? Is this one of those Heisenberg things, where network availability is the time the network _could have_ delivered a packet _when you weren't actually doing so_, while packet loss is the time the network _couldn't_ deliver a packet when you _were_ actually doing so? Is network availability inherently unmeasurable on a network that's less than 100% utilized? Am I over-thinking this? Seriously, though, I know there are people who don't consider SLAs to be fantasy-fiction, and some of them must not be innumerate, and some subset of those must be on NANOG, and the intersection set might be equal to or greater than one, right? Can anybody explain this to me in a way I can translate into code, while still taking myself seriously? -Bill PGP.sig Description: This is a digitally signed message part
