Re: DNS question, null MX records
On Thu, 17 Dec 2009, James Hess wrote: Other tricks may be more obscure, will be less obvious that you don't want mail, and may look like a mistake -- you might even get visitors to your domain contacting you to report the broken MX record. I think that's true with the suggestions in the rest of your post. An alternative to resolving MX to an invalid IP might be to cut to the chase and just make further DNS lookups impossible altogether... Or for that matter delegate the subdomain to 255.255.255.255. The recursive resolvers already have to immediately reject DNS delegation to broadcast addresses and the like. That'll result in a SERVFAIL DNS reply which the MTA will treat as a temporary failure. Remember the aim is to get MTAs to give up on undeliverable mail immediately. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
used hardware..
Hello there.. I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? Mostly juniper stuff thanks in advance. Mehmet
Re: used hardware..
Craigslist Sent from my iPhone 3GS. On Dec 18, 2009, at 7:34 AM, Mehmet Akcin meh...@akcin.net wrote: Hello there.. I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? Mostly juniper stuff thanks in advance. Mehmet
RE: DNS question, null MX records
I concur, in fact I see them come in at precisely the wrong order, lowest preference first in the hopes that we're not running spam filtering on those particular hosts. I have found that putting a bogus mx record at lowest preference slows stuff down though. One of my services is for a company with about 150 mboxes, and I receive no less than 1.5mill spam emails a month for it. -Original Message- From: Paul Vixie [mailto:vi...@isc.org] Sent: Thursday, 17 December 2009 11:48 AM To: na...@merit.edu Subject: Re: DNS question, null MX records Douglas Otis do...@mail-abuse.org writes: If MX TEST-NET became common, legitimate email handlers unable to validate messages prior to acceptance might find their server resource constrained when bouncing a large amount of spam as well. none of this will block spam. spammers do not follow RFC 974 today (since i see a lot of them come to my A RR rather than an MX RR, or in the wrong order). any well known pattern that says don't try to deliver e-mail here will only be honoured by friend people who don't want us to get e-mail we don't want to get. -- Paul Vixie KI6YSY
Re: used hardware..
On Fri, 18 Dec 2009, Mehmet Akcin wrote: Hello there.. I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? Mostly juniper stuff network-res...@network-resell.com -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: used hardware..
just an FYI they are down for a week or so while they relocate that list serv, suppose to be back up in about a week. Brian On Dec 18, 2009, at 9:19 AM, Mikael Abrahamsson wrote: On Fri, 18 Dec 2009, Mehmet Akcin wrote: Hello there.. I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? Mostly juniper stuff network-res...@network-resell.com -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: sink.arpa question
Ted Hardie wrote: Silly question: how well would using 1.0.0.257.in-addr.arpa match the need identified in draft-jabley-sink-arpa ? It seems like it would be equally well guaranteed to be non-existant (short of change in the def of IPv4 and in-addr.arpa). Like sink.arpa, it would get you a valid SOA and nothing else. Am I missing something, or is this operationally equivalent? regards, Ted Isn't the fundamental problem that SMTP can fall back to an implicit MX? None of these solutions will stop spammers from skipping MX records and using direct-to-host connections. Shouldn't we just consider dropping the implicit MX back door as opposed to getting creative with MX records that spammers will surely note and avoid anyway?
Re: sink.arpa question
On Fri, 18 Dec 2009, Jason Bertoch wrote: Isn't the fundamental problem that SMTP can fall back to an implicit MX? None of these solutions will stop spammers from skipping MX records and using direct-to-host connections. This has nothing to do with spam. Shouldn't we just consider dropping the implicit MX back door as opposed to getting creative with MX records that spammers will surely note and avoid anyway? It's impossible to make that kind of incompatible change with an installed base of billions of users. It's already impossible to eliminate the fallback and keep the A fallback. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: sink.arpa question
Tony Finch wrote: On Fri, 18 Dec 2009, Jason Bertoch wrote: Isn't the fundamental problem that SMTP can fall back to an implicit MX? None of these solutions will stop spammers from skipping MX records and using direct-to-host connections. This has nothing to do with spam. For the OP in the original thread, it dealt with spam. I would also argue that spammers abusing the implicit MX, most often through forgeries, provides the biggest motivation to find a fix. Shouldn't we just consider dropping the implicit MX back door as opposed to getting creative with MX records that spammers will surely note and avoid anyway? It's impossible to make that kind of incompatible change with an installed base of billions of users. I wouldn't call it impossible...difficult, maybe. Do metrics exist on how many current installs still rely on the implicit MX? Is the abuse of the implicit MX causing more harm than the effort it would take legacy DNS admins to specify an MX?
Chinese bgp metering story
I have posted sa comment on this from ISOC England on http://www.isoc-ny.org/p2/?p=134 Please feel free to add comments there. -- --- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com ---
Re: sink.arpa question
I wouldn't call it impossible...difficult, maybe. Do metrics exist on how many current installs still rely on the implicit MX? Is the abuse of the implicit MX causing more harm than the effort it would take legacy DNS admins to specify an MX? If I understand your question, you're asking how many sites don't bother with an MX record, but count on the fallback to A to get their mail delivered. I have to say I don't know and don't know of anyone who has checked. I'm not sure that's its even possible to know without starting with a full knowledge of the mail-sending entities out there. Given that many entities allow for subdomain-level mail address (research.example.com, cs.example.edu), the number of extant domain names at some level of the hierarchy would only be a predictor. Possibly someone with a very large mail installation could run statistics to show how often they fell back; that wouldn't be perfect, but it would be somewhat useful. But I think the key question is actually different. Look at this text in RFC 2821: If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the implicit MX rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error. If I put in an MX record pointing to a guaranteed non-present FQDN, someone complying with that text will throw an error rather than keep seeking for an A/. Is *that* useful? If so, then sink.arpa/1.0.0.257.in-addr.arpa as an MX record entry may be. regards, Ted Hardie
Re: Chinese bgp metering story
On Fri, 18 Dec 2009, Joly MacFie wrote: I have posted sa comment on this from ISOC England on http://www.isoc-ny.org/p2/?p=134 Please feel free to add comments there. If anyone has questions about this, the invited experts who managed to wedge their feet in the door at the Kampala meeting were myself, Nishal Goburdhan (AfriNIC), and Michuki Mwangi (ISOC). Any of us would be happy to discuss it. We were there by the grace of the U.S. delegation, which fights the good fight on the Internet's behalf in intergovernmental negotiations like this. Note that there's another big fight coming up over whether the ITU should be allowed to screw up IP address allocation and aggregation. They're not just trying to screw up BGP. Badness abounds. -Bill
Re: Chinese bgp metering story
There is also a discussion of this going on on the IETF discuss list. Regards Marshall On Dec 18, 2009, at 1:19 PM, Joly MacFie wrote: I have posted sa comment on this from ISOC England on http://www.isoc-ny.org/p2/?p=134 Please feel free to add comments there. -- --- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com ---
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 19 Dec, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 307389 Prefixes after maximum aggregation: 142780 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 151105 Total ASes present in the Internet Routing Table: 32965 Prefixes per ASN: 9.32 Origin-only ASes present in the Internet Routing Table: 28621 Origin ASes announcing only one prefix: 13977 Transit ASes present in the Internet Routing Table:4344 Transit-only ASes present in the Internet Routing Table: 96 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 694 Unregistered ASNs in the Routing Table: 131 Number of 32-bit ASNs allocated by the RIRs:360 Prefixes from 32-bit ASNs in the Routing Table: 334 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:165 Number of addresses announced to Internet: 2164856576 Equivalent to 129 /8s, 9 /16s and 23 /24s Percentage of available address space announced: 58.4 Percentage of allocated address space announced: 66.2 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.5 Total number of prefixes smaller than registry allocations: 148286 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:74394 Total APNIC prefixes after maximum aggregation: 25612 APNIC Deaggregation factor:2.90 Prefixes being announced from the APNIC address blocks: 71083 Unique aggregates announced from the APNIC address blocks:31155 APNIC Region origin ASes present in the Internet Routing Table:3897 APNIC Prefixes per ASN: 18.24 APNIC Region origin ASes announcing only one prefix: 1056 APNIC Region transit ASes present in the Internet Routing Table:603 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 485240352 Equivalent to 28 /8s, 236 /16s and 46 /24s Percentage of available APNIC address space announced: 80.3 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:128934 Total ARIN prefixes after maximum aggregation:67391 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 103169 Unique aggregates announced from the ARIN address blocks: 38997 ARIN Region origin ASes present in the Internet Routing Table:13421 ARIN Prefixes per ASN: 7.69 ARIN Region origin ASes announcing only one prefix:5191 ARIN Region transit ASes present in the Internet Routing Table:1330 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 734074144 Equivalent to 43 /8s, 193 /16s and 21 /24s Percentage of available ARIN address space announced: 64.3
Re: Chinese bgp metering story
On Dec 18, 2009, at 1:27 PM, Bill Woodcock wrote: On Fri, 18 Dec 2009, Joly MacFie wrote: I have posted sa comment on this from ISOC England on http://www.isoc-ny.org/p2/?p=134 Please feel free to add comments there. If anyone has questions about this, the invited experts who managed to wedge their feet in the door at the Kampala meeting were myself, Nishal Goburdhan (AfriNIC), and Michuki Mwangi (ISOC). Any of us would be happy to discuss it. We were there by the grace of the U.S. delegation, which fights the good fight on the Internet's behalf in intergovernmental negotiations like this. Could you post a summary, in appropriate technical terms, of precisely what is being requested, and what changes to BGP they want? --Steve Bellovin, http://www.cs.columbia.edu/~smb
RE: used hardware..
We use Network Hardware Resale every couple of months and they are great. I haven't had experience selling anything to them, only purchasing. http://www.networkhardware.com/ Ryan G IT Assistant/Support Technician Limestone Networks, Inc. r.gelob...@limestonenetworks.com www.limestonenetworks.com Simple. Solid. Superior. -Original Message- From: Mehmet Akcin [mailto:meh...@akcin.net] Sent: Friday, December 18, 2009 6:34 AM To: nanog@nanog.org list Subject: used hardware.. Hello there.. I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? Mostly juniper stuff thanks in advance. Mehmet
Re: Chinese bgp metering story
On Dec 18, 2009, at 10:32 AM, Steven Bellovin wrote: Could you post a summary, in appropriate technical terms, of precisely what is being requested, and what changes to BGP they want? Really. I can read tea leaves with the best of them, and the tea leaves I see tell me the reporter (in the story the blog points to) doesn't have a clue. What is the substance of the proposal? Depending on objectives, I would expect that this means that China wants to look at routers (which run BGP), and (a) use IPFIX-or-something to measure traffic rates and charge for trans-China transit, (b) use interface statistics to measure traffic rates and charge for trans-China transit, (c) tax Chinese ISPs for transit services they provide, or maybe (d) use IPFIX-or-something to map communication patterns. It would be (d) that the reporter might seriously want to worry about. But what is all this about is the ITU interested in changing BGP? If the word metering makes any sense in context, BGP doesn't meter anything.
Re: sink.arpa question
Ted Hardie wrote: But I think the key question is actually different. Look at this text in RFC 2821: If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the implicit MX rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error. If I put in an MX record pointing to a guaranteed non-present FQDN, someone complying with that text will throw an error rather than keep seeking for an A/. Is *that* useful? If so, then sink.arpa/1.0.0.257.in-addr.arpa as an MX record entry may be. Yes, I understand the RFC. That section is what allows this topic to be discussed in the first place. sink.arpa may very well be the interim solution, too. It definitely looks better than 0 .. It just seems like an ugly, smelly hack when the fundamental problem lies with allowing the implicit MX. It implies that I should, for the benefit of everyone, create a sink.arpa MX for every A record, where the effort could be better spent dropping the implicit MX rule and requiring an MX record for hosts that really do accept mail. /Jason
Re: Chinese bgp metering story
On Dec 18, 2009, at 1:47 PM, Fred Baker wrote: On Dec 18, 2009, at 10:32 AM, Steven Bellovin wrote: Could you post a summary, in appropriate technical terms, of precisely what is being requested, and what changes to BGP they want? Really. I can read tea leaves with the best of them, and the tea leaves I see tell me the reporter (in the story the blog points to) doesn't have a clue. What is the substance of the proposal? Depending on objectives, I would expect that this means that China wants to look at routers (which run BGP), and (a) use IPFIX-or-something to measure traffic rates and charge for trans-China transit, (b) use interface statistics to measure traffic rates and charge for trans-China transit, (c) tax Chinese ISPs for transit services they provide, or maybe (d) use IPFIX-or-something to map communication patterns. It would be (d) that the reporter might seriously want to worry about. But what is all this about is the ITU interested in changing BGP? If the word metering makes any sense in context, BGP doesn't meter anything. Or using BGP to carry charging information, so that ISPs could use that in their policies? Or charging end-to-end, rather than for transit? --Steve Bellovin, http://www.cs.columbia.edu/~smb
re: used hardware
http://www.networkhardware.com/ContactNHR/ Mostly Cisco, but I think they'll do Juniper. Bill -- -Date: Fri, 18 Dec 2009 04:34:05 -0800 -From: Mehmet Akcin meh...@akcin.net -Subject: used hardware.. -To: nanog@nanog.org list nanog@nanog.org -Message-ID: 16e6d13c-ab9c-4ea5-8e73-59172dd28...@akcin.net -Content-Type: text/plain; charset=us-ascii -Hello there.. -I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? -Mostly juniper stuff -thanks in advance. -Mehmet
Re: Chinese bgp metering story
On 18/12/2009 18:19, Joly MacFie wrote: I have posted sa comment on this from ISOC England on http://www.isoc-ny.org/p2/?p=134 Please feel free to add comments there. I tried to read this article earlier today, but my lolwut meter exploded. It's not really clear whether the confusion in this article is caused by poor understanding on the part of the journalist, the ITU, the European Commission, the UK parliament or China. What is clear is that the article makes very little sense, other than to note that both China and the ITU like the idea of billing for bits at national borders. China, being the sort of state that it is, is perfectly welcome to impose restrictions like metering for traffic and imposing billing regimes on international players. The net result of this will probably be to trash China's network international connectivity, as the rest of the world mouths a collective whatever, dude... and then goes back to reading their less spamful inbox. The ITU, for its part, seems to be involved in a desperate bid to make itself relevant to the internet world - an ironic position, considering they did their level best to squat on the internet in the early 90s and ignore it in the late 90s and early noughties. Part of this desperation is manifesting itself as a movement by a number of countries to introduce international tariffing of internet bits and bytes at country borders. For some reason, this peculiar notion appears to make sense to governments and national telcos - presumably because that's how it works in the PSTN world. If all you have is a nail, everything looks like a hammer. This isn't the only irrelevant absurdity being proposed by the ITU just now. If you really want to have a good belly laugh at the level of misunderstanding by the ITU of how the internet actually works, just take a look at this document, which followed ITU Resolution 64: http://www.itu.int/dms_pub/itu-t/oth/3B/02/T3B02020002PDFE.pdf In the mean-time, I am refilling my lolwut meter with a quadruple supply of wtfs, in preparation for the ITU's next move. There's a more serious aspect to this; the ITU is largely irrelevant to the Internet, and their actions indicate that they strongly resent this. And there is nothing more dangerous than a well-funded bureaucracy which realises that it is now - to all intents and purposes - irrelevant. Nick
Re: used hardware
I buy a lot of gear from Peter Giberd at Townsend. I have been working with him for a good 7 years. It's budded into a friendship, good people there. -B http://www.townsendassets.com/ On Dec 18, 2009, at 11:03 AM, Bill Lewis wrote: http://www.networkhardware.com/ContactNHR/ Mostly Cisco, but I think they'll do Juniper. Bill -- -Date: Fri, 18 Dec 2009 04:34:05 -0800 -From: Mehmet Akcin meh...@akcin.net -Subject: used hardware.. -To: nanog@nanog.org list nanog@nanog.org -Message-ID: 16e6d13c-ab9c-4ea5-8e73-59172dd28...@akcin.net -Content-Type: text/plain; charset=us-ascii -Hello there.. -I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? -Mostly juniper stuff -thanks in advance. -Mehmet
Re: Chinese bgp metering story
SIIA Chair Simon Tay on Clinton's Asia visit (Bloomberg, 20th Feb 2009): Steve Engel (Bloomberg): Speaking of provoking, where do you see Hillary bringing the tact in bringing the issues that Obama wants to raise to the Chinese in her trip this time. Yuan revaluation is one, and also of course human rights is top of the agenda. Is she going to be offending her host here? Simon Tay: Well, I think, China is the most important relationship that America has got across the Pacific. It's vital to them, and it's vital to everyone, and there are a couple of nasty missteps that could be made. I think the currency issue after the Tim Geithner confirmation statement would be one of the trickiest things to do. I think the downturn in China has been understood in America. The Chinese have their own domestic audience, their own domestic concerns, and if I were Clinton's advisor, I would tell Clinton, please don't go there too hard and too fast. I think that the human rights issue is similar. I think the America-China realtionship needs to go beyond these hotspots, whether it's Tibet, or currency, and really start off on something more positive. I mean, the tradition is (that) every (US) President starts off China wrong, and spends the next six years or so trying to get it right. It would be nice to see Clinton do something different and get it right from the start. On 12/18/09 2:03 PM, Nick Hilliard n...@foobar.org wrote: On 18/12/2009 18:19, Joly MacFie wrote: I have posted sa comment on this from ISOC England on http://www.isoc-ny.org/p2/?p=134 Please feel free to add comments there. I tried to read this article earlier today, but my lolwut meter exploded. It's not really clear whether the confusion in this article is caused by poor understanding on the part of the journalist, the ITU, the European Commission, the UK parliament or China. What is clear is that the article makes very little sense, other than to note that both China and the ITU like the idea of billing for bits at national borders. China, being the sort of state that it is, is perfectly welcome to impose restrictions like metering for traffic and imposing billing regimes on international players. The net result of this will probably be to trash China's network international connectivity, as the rest of the world mouths a collective whatever, dude... and then goes back to reading their less spamful inbox. The ITU, for its part, seems to be involved in a desperate bid to make itself relevant to the internet world - an ironic position, considering they did their level best to squat on the internet in the early 90s and ignore it in the late 90s and early noughties. Part of this desperation is manifesting itself as a movement by a number of countries to introduce international tariffing of internet bits and bytes at country borders. For some reason, this peculiar notion appears to make sense to governments and national telcos - presumably because that's how it works in the PSTN world. If all you have is a nail, everything looks like a hammer. This isn't the only irrelevant absurdity being proposed by the ITU just now. If you really want to have a good belly laugh at the level of misunderstanding by the ITU of how the internet actually works, just take a look at this document, which followed ITU Resolution 64: http://www.itu.int/dms_pub/itu-t/oth/3B/02/T3B02020002PDFE.pdf In the mean-time, I am refilling my lolwut meter with a quadruple supply of wtfs, in preparation for the ITU's next move. There's a more serious aspect to this; the ITU is largely irrelevant to the Internet, and their actions indicate that they strongly resent this. And there is nothing more dangerous than a well-funded bureaucracy which realises that it is now - to all intents and purposes - irrelevant. Nick
Re: Chinese bgp metering story
On Dec 19, 2009, at 1:47 AM, Fred Baker wrote: I can read tea leaves with the best of them, and the tea leaves I see tell me the reporter (in the story the blog points to) doesn't have a clue. What is the substance of the proposal? The report seemed a reasonably accurate account of what went on in Kampala. But what is all this about is the ITU interested in changing BGP? If the word metering makes any sense in context, BGP doesn't meter anything. The Chinese delegation presented a dozen pages of formulae involving 20+ variables, infinite sums, and other mathematical goodies. Wowing the audience I guess. The whole way through using BGP was mentioned - in the sense of pulling data from, and adding data to BGP for the purposes of evaluating these formulae. It was clear that BGP would be used - and modified if need be - to achieve this. Mixing billing with the reachability information signalled through BGP just doesn't seem like a good idea. Interesting to note was that nowhere was the intent of all this mentioned, which is presumably to calculate the value each and every party's traffic traversing a link generates, and to apportion costs accordingly. Misguided, nonsensical, and unworkable ideas often gain traction. It's important that this one doesn't. Cheers, Jonny.
RE: Chinese bgp metering story
From the BBC article quoted in the isoc-ny.org link: An ITU spokesman said: The ITU has no plans to modify the BGP protocol, which is not an ITU-T standard. A proposal has been made, and is being studied, to use BGP routers to collect traffic flow data, which could be used, by bilateral agreement, by operators for billing purposes. I read this to mean, no news here. If you want to move traffic, you need a bilateral agreement. That already exists. Where/if money flows, we know circuits don't build themselves for free, so the question of using money isn't a question. The only question is whether you are adjusting based on usage, or ports, or total speed, or direction of bits. ITU is already acknowledging that BGP isn't its baby, so it has nothing to say there. Deepak
Re: Chinese bgp metering story
On Dec 18, 2009, at 2:24 PM, Jonny Martin wrote: On Dec 19, 2009, at 1:47 AM, Fred Baker wrote: I can read tea leaves with the best of them, and the tea leaves I see tell me the reporter (in the story the blog points to) doesn't have a clue. What is the substance of the proposal? The report seemed a reasonably accurate account of what went on in Kampala. But what is all this about is the ITU interested in changing BGP? If the word metering makes any sense in context, BGP doesn't meter anything. The Chinese delegation presented a dozen pages of formulae involving 20+ variables, infinite sums, and other mathematical goodies. Wowing the audience I guess. The whole way through using BGP was mentioned - in the sense of pulling data from, and adding data to BGP for the purposes of evaluating these formulae. It was clear that BGP would be used - and modified if need be - to achieve this. Mixing billing with the reachability information signalled through BGP just doesn't seem like a good idea. Is this 12+ page presentation available anywhere ? Regards Marshall Interesting to note was that nowhere was the intent of all this mentioned, which is presumably to calculate the value each and every party's traffic traversing a link generates, and to apportion costs accordingly. Misguided, nonsensical, and unworkable ideas often gain traction. It's important that this one doesn't. Cheers, Jonny.
Re: Chinese bgp metering story
On Dec 19, 2009, at 2:24 AM, Jonny Martin wrote: Mixing billing with the reachability information signalled through BGP just doesn't seem like a good idea. This is done all the time via combinatorial BGP/NetFlow analysis, for peering/transit analysis reports, offnet/on-net billing differentials, etc. The merits (or lack thereof) of the 'proposal' in question aside, there's nothing evil or stupid about doing this on one's own network. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Chinese bgp metering story
On Dec 19, 2009, at 2:26 AM, Deepak Jain wrote: A proposal has been made, and is being studied, to use BGP routers to collect traffic flow data, which could be used, by bilateral agreement, by operators for billing purposes. Lots of 'BGP routers' are used to collect traffic flow data (NetFlow, cflowd, S/flow, NetStream, IPFIX, et. al.) to do this, ever single second of every single day, all around the world - including in China. It sounds as if the erstwhile proponents of this plan need to catch up to 1997 in terms of their operational clue. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
RE: Chinese bgp metering story
On Fri, 18 Dec 2009, Deepak Jain wrote: ITU is already acknowledging that BGP isn't its baby, so it has nothing to say there. Yes, that was the successful (for us) outcome of the meeting, which would not have been the case had we not been prepared and had people there. Just to explain the general danger here... The ITU is the standards body in which international spectrum allocations and satellite lots are negotiated. No industrialized country will withdraw from that. Because it's an international treaty organization, member countries are bound to enforce the outcome of its decisions within their jurisdictions, regardless of whether they agreed with the decision or not. If the ITU had decided to take the BGP spec from the IETF, the IETF could easily have told them to take a hike, but national governments could not have done so, and that would put national governments in the very uncomfortable position of having to try to enact or support that change in law somehow. With the BGP spec, this all seems a bit ridiculous and abstract, but with IP allocation, the danger is a little more immediate. The decision on that will mostly be made in mid-March. -Bill
Re: Chinese bgp metering story
On Dec 19, 2009, at 1:47 AM, Fred Baker wrote: But what is all this about is the ITU interested in changing BGP? If the word metering makes any sense in context, BGP doesn't meter anything. Neither the reporter nor the Chinese proponents nor the ITU seem to understand that making use of combined flow telemetry/BGP analytics for traffic engineering, capacity planning, and billing applications has been a common practice for the last 13 or so years. This seems to pretty much be a non-story, except for the nationalization aspect of it. I concur with Nick's hypothesis that the actual end-goal may be to 'harmonize' trans-national peering agreements/transit fees, and then tax them (probably regressively in terms of transnational traffic) - with a sidecar of surveillance for good measure. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Chinese bgp metering story
On Dec 19, 2009, at 2:49 AM, Bill Woodcock wrote: The decision on that will mostly be made in mid-March. By whom? The RIRs aren't just going to say, OK, ITU folks, it's all yours, heh. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
RE: used hardware..
Our results with NHR were a disaster - that's all I'm say on a public list. I highly recommend Knowledge Computers anytime someone asks - mention my name as a reference and you'll get a good price for sure ;) Hit me up offline for contact details should you wish... Paul -Original Message- From: Ryan Gelobter [mailto:r.gelob...@limestonenetworks.com] Sent: December-18-09 1:38 PM To: Mehmet Akcin; nanog@nanog.org list Subject: RE: used hardware.. We use Network Hardware Resale every couple of months and they are great. I haven't had experience selling anything to them, only purchasing. http://www.networkhardware.com/ Ryan G IT Assistant/Support Technician Limestone Networks, Inc. r.gelob...@limestonenetworks.com www.limestonenetworks.com Simple. Solid. Superior. -Original Message- From: Mehmet Akcin [mailto:meh...@akcin.net] Sent: Friday, December 18, 2009 6:34 AM To: nanog@nanog.org list Subject: used hardware.. Hello there.. I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? Mostly juniper stuff thanks in advance. Mehmet The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
Re: Chinese bgp metering story
On Fri, 18 Dec 2009, Dobbins, Roland wrote: The decision on that will mostly be made in mid-March. By whom? A working group of the ITU Council. The RIRs aren't just going to say, OK, ITU folks, it's all yours, heh. Indeed not. However, the RIRs don't have a voice in the decision. This is an intergovernmental decision within the ITU Council. If the ITU Council were to decide that it's a good idea for the ITU to take over IP addressing and break it, they would then take it to the ITU Plenipotentiary. At that point, it could become policy of the treaty organization, and then member country governments would become bound to support the policy in their own legal structures. Odds are that would be expressed in laws similar to that of Korea, where it's illegal for network operators to get IP addresses from APNIC, their RIR, and they must instead get them from KRNIC, a Korean governmental agency. Which, in turn, proxies their votes in the APNIC elections, but that's another story. :-) -Bill
Re: used hardware..
Not advocating NHR, but I bought one 6509 switch with several blades and no trouble for about a year. -Azher Paul Stewart wrote: Our results with NHR were a disaster - that's all I'm say on a public list. I highly recommend Knowledge Computers anytime someone asks - mention my name as a reference and you'll get a good price for sure ;) Hit me up offline for contact details should you wish... Paul -Original Message- From: Ryan Gelobter [mailto:r.gelob...@limestonenetworks.com] Sent: December-18-09 1:38 PM To: Mehmet Akcin; nanog@nanog.org list Subject: RE: used hardware.. We use Network Hardware Resale every couple of months and they are great. I haven't had experience selling anything to them, only purchasing. http://www.networkhardware.com/ Ryan G IT Assistant/Support Technician Limestone Networks, Inc. r.gelob...@limestonenetworks.com www.limestonenetworks.com Simple. Solid. Superior. -Original Message- From: Mehmet Akcin [mailto:meh...@akcin.net] Sent: Friday, December 18, 2009 6:34 AM To: nanog@nanog.org list Subject: used hardware.. Hello there.. I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? Mostly juniper stuff thanks in advance. Mehmet The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
Re: Chinese bgp metering story
My sense is that the ITU has played with such ideas in the past, and the governments have for the most part found it in their interest to not screw with the Internet. Do you have any specific recommendations on how to keep that true? On Dec 18, 2009, at 12:05 PM, Bill Woodcock wrote: On Fri, 18 Dec 2009, Dobbins, Roland wrote: The decision on that will mostly be made in mid-March. By whom? A working group of the ITU Council. The RIRs aren't just going to say, OK, ITU folks, it's all yours, heh. Indeed not. However, the RIRs don't have a voice in the decision. This is an intergovernmental decision within the ITU Council. If the ITU Council were to decide that it's a good idea for the ITU to take over IP addressing and break it, they would then take it to the ITU Plenipotentiary. At that point, it could become policy of the treaty organization, and then member country governments would become bound to support the policy in their own legal structures. Odds are that would be expressed in laws similar to that of Korea, where it's illegal for network operators to get IP addresses from APNIC, their RIR, and they must instead get them from KRNIC, a Korean governmental agency. Which, in turn, proxies their votes in the APNIC elections, but that's another story. :-) -Bill http://www.ipinc.net/IPv4.GIF
Re: Chinese bgp metering story
Why can't we carry price per kilosegment on BGP ? And don't be so hard on the ITU folks, the only thing they want to break is the monopoly of IP address allocation. J
Re: Chinese bgp metering story
On Dec 18, 2009, at 12:43 PM, Jorge Amodio wrote: And don't be so hard on the ITU folks, the only thing they want to break is the monopoly of IP address allocation. With all due respect, they don't want to break said monopoly, assuming one agrees that it is a monopoly (I think there's a lot more to the story than that, but that's another discussion). They want to *be* said monopoly.
Re: Chinese bgp metering story
On Fri, Dec 18, 2009 at 2:53 PM, Fred Baker f...@cisco.com wrote: On Dec 18, 2009, at 12:43 PM, Jorge Amodio wrote: And don't be so hard on the ITU folks, the only thing they want to break is the monopoly of IP address allocation. With all due respect, they don't want to break said monopoly, assuming one agrees that it is a monopoly (I think there's a lot more to the story than that, but that's another discussion). They want to *be* said monopoly. Indeed !!! I was being sarcastic, I was watching live the last IGF meeting when by proxy ICANN's CEO got grilled with the question about IPv6 address allocation. Jorge
Rackspace outage
Rackspace seems to have a severe routing loop, which appears to have taken a lot of sites down. Does anyone have any information on this? Host Loss% Last Avg Best Wrst StDev 1. ssg-vlan1011.lindon.pei 0.0% 0.2 0.2 0.1 1.2 0.2 2. pub-192-41-10-33.center7.com 0.0% 0.8 2.2 0.7 77.0 8.0 3. pub-192-41-0-37.center7.com 0.0% 0.4 0.4 0.3 9.7 0.5 4. s3-1-0-28--0.gw03.slkc.eli.net 0.0% 159.4 11.4 1.4 201.5 34.4 5. tg9-1.cr02.slkcutxd.integra.net 0.0% 183.4 48.4 29.2 233.2 48.3 6. tg9-1.cr01.dnvrcoet.integra.net 0.0% 201.2 50.5 29.2 246.2 49.4 7. tg13-1.cr01.dllstx97.integra.net 0.0% 111.2 45.4 29.2 230.2 46.2 8. tg1-1.br01.dllstx97.integra.net 0.0% 113.7 38.4 29.3 222.8 33.1 9. eq-dfw.rackspace.net 2.8% 428.8 738.2 229.4 1416. 200.2 10. core5-bbr1-vlan2005.dfw1.rackspace.net 88.8% 51.4 116.8 46.8 351.3 73.5 core5-bbr1-vlan3005.dfw1.rackspace.net core1-bbr1-vlan2001.dfw1.rackspace.net core1-bbr1-vlan3001.dfw1.rackspace.net core3-bbr1-vlan3003.dfw1.rackspace.net 11. bbr1-core5-vlan2005.dfw1.rackspace.net 91.6% 648.7 595.6 245.0 1014. 197.9 bbr1-core5-vlan3005.dfw1.rackspace.net bbr1-core1-vlan3001.dfw1.rackspace.net bbr1-core1-vlan2001.dfw1.rackspace.net bbr1-core3-vlan3003.dfw1.rackspace.net intra-core3-core1.dfw1.rackspace.com 12. core5-bbr1-vlan2005.dfw1.rackspace.net 89.7% 139.3 153.9 46.6 439.3 109.8 core5-bbr1-vlan3005.dfw1.rackspace.net core1-bbr1-vlan3001.dfw1.rackspace.net core1-bbr1-vlan2001.dfw1.rackspace.net core3-bbr1-vlan3003.dfw1.rackspace.net 13. bbr1-core5-vlan2005.dfw1.rackspace.net 91.1% 475.6 642.1 91.9 1516. 296.1 bbr1-core5-vlan3005.dfw1.rackspace.net bbr1-core1-vlan3001.dfw1.rackspace.net bbr1-core1-vlan2001.dfw1.rackspace.net bbr1-core3-vlan3003.dfw1.rackspace.net core1-bbr1-vlan3001.dfw1.rackspace.net 14. core5-bbr1-vlan2005.dfw1.rackspace.net 91.9% 147.4 170.8 66.0 475.1 122.6 core5-bbr1-vlan3005.dfw1.rackspace.net core1-bbr1-vlan3001.dfw1.rackspace.net core1-bbr1-vlan2001.dfw1.rackspace.net core3-bbr1-vlan3003.dfw1.rackspace.net intra-core3-core1.dfw1.rackspace.com --Justin
BGP Update Report
BGP Update Report Interval: 10-Dec-09 -to- 17-Dec-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS23577 16590 2.0% 24.1 -- ATM-MPLS-AS-KR Korea Telecom 2 - AS28477 13270 1.6%1474.4 -- Universidad Autonoma del Esstado de Morelos 3 - AS984212792 1.5% 799.5 -- LDCC-AS Lotte Data Communication Company 4 - AS682211009 1.3% 550.5 -- SUPERONLINE-AS SuperOnline autonomous system 5 - AS5800 8918 1.1% 48.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS8551 8775 1.1% 26.4 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone 7 - AS358058542 1.0% 17.6 -- UTG-AS United Telecom AS 8 - AS345848010 1.0% 98.9 -- KHBDSV AS for ISP - Khabarovsk Telecommunication Center 9 - AS8452 7516 0.9% 12.7 -- TEDATA TEDATA 10 - AS9198 7361 0.9% 15.6 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 11 - AS7643 7064 0.8% 32.4 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 12 - AS4249 6412 0.8% 36.9 -- LILLY-AS - Eli Lilly and Company 13 - AS9829 6376 0.8% 14.1 -- BSNL-NIB National Internet Backbone 14 - AS111395642 0.7% 14.1 -- CWRIN CW BARBADOS 15 - AS5434 5350 0.6% 47.3 -- NURSAT-ALA-AS Nursat-Almaty 16 - AS179644880 0.6% 69.7 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. 17 - AS5803 4388 0.5% 50.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS341374180 0.5% 149.3 -- RUAMUR-AS Far east Telecommunications Company AS 19 - AS8151 4157 0.5% 5.7 -- Uninet S.A. de C.V. 20 - AS179743750 0.5% 9.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS276672846 0.3%2846.0 -- Universidad Autonoma de la Laguna 2 - AS487542591 0.3%2591.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 3 - AS8909 2468 0.3%2468.0 -- AMURSU-AS AMURSU Autonomous System 4 - AS393841892 0.2%1892.0 -- GUILAN-UNIV-AS University of Guilan AS System 5 - AS142511879 0.2%1879.0 -- MLSLI - Multiple Lising Service of Long Island, Inc. 6 - AS459271481 0.2%1481.0 -- SCCL-123-IN THE SINGARENI COLLIERIES COMPANY LIMITED 7 - AS28477 13270 1.6%1474.4 -- Universidad Autonoma del Esstado de Morelos 8 - AS5691 2763 0.3%1381.5 -- MITRE-AS-5 - The MITRE Corporation 9 - AS151451213 0.1%1213.0 -- GLOBALSCAPE - GlobalSCAPE, Inc. 10 - AS4270 2796 0.3% 932.0 -- Red de Interconexion Universitaria 11 - AS984212792 1.5% 799.5 -- LDCC-AS Lotte Data Communication Company 12 - AS178191977 0.2% 659.0 -- ASN-EQUINIX-AP Equinix Asia Pacific 13 - AS41368 645 0.1% 645.0 -- TVALMANSA-ASN TV ALMANSA, Servicios de Comunicacion 14 - AS398031264 0.1% 632.0 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 15 - AS682211009 1.3% 550.5 -- SUPERONLINE-AS SuperOnline autonomous system 16 - AS34787 460 0.1% 460.0 -- LYAKH-AS PF Volodymyr Lyakh 17 - AS6453 1266 0.1% 422.0 -- GLOBEINTERNET TATA Communications 18 - AS25585 416 0.1% 416.0 -- KENCOMP Kencomp Internet LTD, Small UK Internet Provider 19 - AS47559 400 0.1% 400.0 -- TSCNET-AS SC Tele Satelyt Company SRL 20 - AS37136 351 0.0% 351.0 -- ETISALAT-AS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/2413158 1.4% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 89.144.140.0/244551 0.5% AS39308 -- ASK-AS Andishe Sabz Khazar Autonomous System AS39384 -- GUILAN-UNIV-AS University of Guilan AS System 3 - 143.138.107.0/24 3027 0.3% AS747 -- TAEGU-AS - Headquarters, USAISC 4 - 148.245.181.0/24 2846 0.3% AS27667 -- Universidad Autonoma de la Laguna 5 - 170.210.56.0/222792 0.3% AS4270 -- Red de Interconexion Universitaria 6 - 192.12.120.0/242761 0.3% AS5691 -- MITRE-AS-5 - The MITRE Corporation 7 - 91.212.23.0/24 2591 0.3% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 8 - 202.5.154.0/24 2492 0.3% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 9 - 62.76.124.0/23 2468 0.3% AS8909 -- AMURSU-AS AMURSU Autonomous System 10 - 203.162.118.128/ 2262 0.2% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 11 - 65.223.235.0/241879 0.2% AS14251 -- MLSLI - Multiple Lising
The Cidr Report
This report has been generated at Fri Dec 18 21:11:23 2009 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
11-12-09311684 190297
12-12-09308771 192299
13-12-09311685 192429
14-12-09311744 192541
15-12-09311908 192248
16-12-09312103 192508
17-12-09312072 192815
18-12-09312972 192767
AS Summary
33185 Number of ASes in routing system
14122 Number of ASes announcing only one prefix
4367 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
92551424 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 18Dec09 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 312769 192732 12003738.4% All ASes
AS6389 4187 309 387892.6% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4367 1948 241955.4% TWTC - tw telecom holdings,
inc.
AS1785 1796 342 145481.0% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4766 1892 585 130769.1% KIXS-AS-KR Korea Telecom
AS17488 1458 311 114778.7% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS22773 1122 71 105193.7% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS8151 1580 677 90357.2% Uninet S.A. de C.V.
AS4755 1280 395 88569.1% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS19262 1048 234 81477.7% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS8452 1035 312 72369.9% TEDATA TEDATA
AS18101 994 320 67467.8% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS10620 1003 337 66666.4% TV Cable S.A.
AS6478 468 64357.9% ATT-INTERNET3 - ATT WorldNet
Services
AS18566 1059 444 61558.1% COVAD - Covad Communications
Co.
AS4808 787 208 57973.6% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS3356 1199 629 57047.5% LEVEL3 Level 3 Communications
AS4804 633 70 56388.9% MPX-AS Microplex PTY LTD
AS4134 1016 454 56255.3% CHINANET-BACKBONE
No.31,Jin-rong Street
AS7303 665 103 56284.5% Telecom Argentina S.A.
AS24560 813 253 56068.9% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS7018 1589 1035 55434.9% ATT-INTERNET4 - ATT WorldNet
Services
AS17908 765 241 52468.5% TCISL Tata Communications
AS7545 934 418 51655.2% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS11492 1151 654 49743.2% CABLEONE - CABLE ONE, INC.
AS22047 545 50 49590.8% VTR BANDA ANCHA S.A.
AS4780 642 151 49176.5% SEEDNET Digital United Inc.
AS28573 828 366 46255.8% NET Servicos de Comunicao S.A.
AS9443 531 78 45385.3% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS9299 662 220 44266.8% IPG-AS-AP Philippine Long
Distance Telephone Company
AS35805 471 29 44293.8% UTG-AS United Telecom AS
Total 37163117122545168.5% Top 30 total
Possible Bogus Routes
41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service
41.223.188.0/24
Re: Chinese bgp metering story
And don't be so hard on the ITU folks, the only thing they want to break is the monopoly of IP address allocation. That's OK with me if they're willing to let the IETF break the monopoly on telephone number allocation. R's, John
Re: Rackspace outage
On Dec 18, 2009, at 1:58 PM, Justin T. Sharp wrote: Rackspace seems to have a severe routing loop, which appears to have taken a lot of sites down. Does anyone have any information on this? http://status.mosso.com/2009/12/cloud-sites-dfw-investigating-current-issue.html
Re: sink.arpa question
In message 4b2bcea2.7010...@i6ix.com, Jason Bertoch writes: Ted Hardie wrote: But I think the key question is actually different. Look at this text in RFC 2821: If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the implicit MX rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error. If I put in an MX record pointing to a guaranteed non-present FQDN, someone complying with that text will throw an error rather than keep seeking for an A/. Is *that* useful? If so, then sink.arpa/1.0.0.257.in-addr.arpa as an MX record entry may be. Yes, I understand the RFC. That section is what allows this topic to be discussed in the first place. sink.arpa may very well be the interim solution, too. It definitely looks better than 0 .. It just seems like an ugly, smelly hack when the fundamental problem lies with allowing the implicit MX. It implies that I should, for the benefit of everyone, create a sink.arpa MX for every A record, where the effort could be better spent dropping the implicit MX rule and requiring an MX record for hosts that really do accept mail. /Jason MX 0 . is not useable. . is not a legal host name. For those MTA's that ignore the legal hostname rule there shouldn't be any address records at . which also make it unusable. And for those of you worring about DNSSEC costs. NODATA is 1 NSEC/NSEC3 record unless it is from a wildcard where there are some addition records, whereas NXDOMAIN is usually 2 NSEC or 3 NSEC3 records + signatures. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Chinese bgp metering story
Nobody here remembers ICAIS? This is actually an old story/ambition, which started elsewhere, and not long after the the 1997-1998 rebalancing of ITU-mediated switched telecom settlements. Two nuggets from the history books pasted in below. Of course, just because it's not new doesn't mean that it's not newsworthy. As I recall, this issue precipitated a fairly titanic behind-the-scenes struggle last time around... TV _ AAP NEWSFEED July 15, 1999, Thursday Telstra chief calls for equitable Net traffic cost sharing SYDNEY, July 15 AAP - Telstra Corp Ltd chief executive Ziggy Switkowski today called for an equitable arrangement for sharing the cost of carrying Internet traffic to and from the United States.In an address to the Asia-Pacific Economic Cooperation (APEC) business conference here, Dr Switkowski said US operators were currently enjoying an implied subsidy of 30 per cent of the costs of international Internet connection... The charging system operates on a similar principle to that used in international phone charging arrangements, he said. For Australia alone, that represents approximately $50 million a year, and the sum varies from country to country depending on usage, Dr Switkowski said. Telstra's view is that the future of e-commerce could be undermined if investment in capacity growth does not match growth in demand. But infrastructure providers outside the US need to have sufficient confidence in cost sharing to invest in new capacity to meet the exploding demand for bandwidth... _ Economist October 19, 1996 Too cheap to meter? The fact that the Internet seems free to many of its users has been one reason for its success. Now it may have to change. But how? ...If the costs of the telephone companies and the Internet are similar, why are their methods of pricing different? The answer is that telecoms charges bear little relation to costs. The telephone industry is regulated nearly everywhere and in most countries prices are set by bureaucrats and commissions; real costs are hidden by a layer of crosssubsidies. The Internet, on the other hand, is essentially unregulated. At present, telephone companies typically make less than half their revenue from fixed charges rather than from the price of each call. Tim Kelly, of the International Telecommunication Union in Geneva, reckons that the share of revenue from connection charges and monthly rentals has risen in the past decade from about 33% to 40%; he expects an increase to around 60% over the next ten years. The companies are not keen on such rebalancing, since it usually involves reducing lucrative call charges rather than increasing fixed charges. But without it, they are vulnerable to competition, including competition from the Internet, which can offer rival services far less expensively... ...Such settlements are a source of endless argument: America's long- distance carriers complain that local telephone companies overcharge them. Moreover, they transfer huge sums of money between countries: in 1994, carriers based in the United States handed over a net $ 4.3 billion to foreign carriers. Because countries in which telephoning is cheap (such as America) tend to ring countries where calls are dearer, American carriers grumble that they are subsidising the inefficient and uncompetitive. Gradually, therefore, telephone companies are moving towards a sender-keeps-all system, where they will charge each other a flat fee for access to a certain amount of transmission capacity, rather than bill each other on the basis of use. That would bring them increasingly into line with what happens on the Internet, where settlement is rudimentary. There are payments between each of the Internet's hierarchy of links: access providers pay their regional network and regional networks pay the companies that operate the high-capacity long-distance parts, the backbone of the system. But such payments are mostly based on the availability of capacity, not its use: service providers simply agree to carry each other's traffic without totting up precise bills. This encourages a hot-potato approach: Internet access providers hand traffic on as quickly as possible to the carrier taking it to its ultimate destination. That benefits small service providers and irritates big ones, who say they get little reward for the effort of carrying the traffic for most of its journey. In turn, this lessens their incentive to invest in new capacity. The problem of settlement is worse for access providers outside America. Led by Singapore Telecom and Australia's Telstra, they complain that they have to pay all the cost of leasing lines between their country and the United States. The rest of the planet subsidises the United States, argues Barry Greene, who works for Cisco, a maker of routers, but was previously with Singnet,
Routing to multiple uplinks
This may be slightly off topic however I have a very unique situation where I need to provide two diverse paths to a major stock exchange. Each host may either use route A or B for any given reason to access this particular exchange using two distinct routers and target address. The applicatiOn running on these hosts must only see/use one target address this needs to be transparent as possible. NIC bonding/teaming on the host side isn't a viable solution because of the latency overhead same goes for vrrp/hsrp. I believe my only option here is to setup multiple default routes with a preferred path of some sort. This seems to be possible using ip route2 on Linux. This just seems wrong on many levels and I thought I would post here because I know there is something obvious I'm missing. Please clue me in. Thanks. Sent from my iPhone 3GS.
Re: Routing to multiple uplinks
rodrick brown wrote: This may be slightly off topic however I have a very unique situation where I need to provide two diverse paths to a major stock exchange. Each host may either use route A or B for any given reason to access this particular exchange using two distinct routers and target address. Have you considered point-to-point circuits? The applicatiOn running on these hosts must only see/use one target address this needs to be transparent as possible. NIC bonding/teaming on the host side isn't a viable solution because of the latency overhead same goes for vrrp/hsrp. What latency do you mean when you talk about NIC bonding and VRRP? Peter
Re: Routing to multiple uplinks
On Fri, 18 Dec 2009 19:46:42 EST, rodrick brown said: The applicatiOn running on these hosts must only see/use one target address this needs to be transparent as possible. NIC bonding/teaming on the host side isn't a viable solution because of the latency overhead same goes for vrrp/hsrp. If you're worried about the latency issues with NIC bonding, what do you intend to do about the speed-of-light latency from Chicago to NYC? pgpyuajDF54i8.pgp Description: PGP signature
Re: Chinese bgp metering story
On Fri, Dec 18, 2009 at 1:24 PM, Jonny Martin jo...@pch.net wrote: On Dec 19, 2009, at 1:47 AM, Fred Baker wrote: .. modified if need be - to achieve this. Mixing billing with the reachability information signalled through BGP just doesn't seem like a good idea. Indeed not.. but it might offer one advantage, if it was mandatory for any such tarrif/cost to be advertised there to be valid, and in the form of an ancillary BGP route attribute, rather than buried in some 500,000 page treaty that forces all ISPs to decipher it and try to figure out what their liabilities are. Mainly because it makes any tarrif very visible, and easily understood. and offers an easy ability to automatically make decisions like discard reachability information that has any billing labels or strings attached to it, or has a cost greater than $X per million packets listed for 'source'... and easily allows an ISP to replace the next hop with null when a tarrif option has been listed, or use only a route not subject to tarrif. Thus treating as unroutable or permit routing around any transit that would like to try to taint its routes by indicating tarrif to peers.And thus also permitting the whole notion of 'IP tarrif' to see a very quick death... Otherwise, new router hardware could more easily provide suitable counters and IPFIX data (with suitable changes to ip flow export formats) to track the tarrifs due to all tarrif payee IDs, or whatever that would be. -- -J
Re: Chinese bgp metering story
On Dec 19, 2009, at 11:09 AM, James Hess wrote: Otherwise, new router hardware could more easily provide suitable counters and IPFIX data (with suitable changes to ip flow export formats) to track the tarrifs due to all tarrif payee IDs, or whatever that would be. Existing hardware does this today with NetFlow, et. al. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
