Re: The End-To-End Internet (was Re: Blocking MX query)
Subject: Re: The End-To-End Internet (was Re: Blocking MX query) Date: Wed, Sep 05, 2012 at 06:56:36PM -0400 Quoting William Herrin (b...@herrin.us): Thing is, spam levels *are* down a good 20% in the last couple years, that being about the time ISPs began doing this. More, 20% *is* in rough proportion the impacted customer counts on the handful of cable and DSL providers that implemented it. Not here. My experience is that it is at best static, but most likely increasing. Around here, the sad default is that it is impossible to buy tcp/25 access except in colos and over tunnels. It does not help. It just is a very bad precedent, it looks like you are doing something. Which for lawyers is just as fine as efficient action. We need to remind ourselves that this Internet thing got big simply because it let people have computers send packets directly to other peoples computers. There was this guy called Aesop who wrote a story about blocking traffic on the Internet, but since the Internet wasn't known at the time (too secret) he had to rephrase it so it became a story about a goose that lays golden eggs. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I HAVE to buy a new DODGE MISER and two dozen JORDACHE JEANS because my viewscreen is USER-FRIENDLY!! signature.asc Description: Digital signature
Re: The End-To-End Internet (was Re: Blocking MX query)
My idealistic preference would be the ISP allows outbound port 25, but are highly responsive to abuse complaints; My idealistic preference is that ISPs not let their botted customers fill everyone's inbox with garbage. Why do you think that blocking port 25 precludes logging what they block, and dealing with customers whose traffic shows that they're botted? R's, John
Re: RPKI Pilot Participant Notice
I'd wager what ARIN is going to do in said Relying Party Agreement is tell RPs (i.e., *relying* parties) that they ought not rely to much on the data for routing, and if they do and something gets hosed, ARIN's not at fault -- but I'll wait to read the actual agreement before speculating more. that too is my *speculation*. which would be interesting, as accurate primary data is arin's primary responsibility. but anyone who has looked at any of the rirs' data seriously needed a strong stomach. randy
Re: RPKI Pilot Participant Notice
On Sep 5, 2012, at 8:24 PM, Christopher Morrow morrowc.li...@gmail.com wrote: In order to access the production RPKI TAL, you will first have to agree to ARIN's Relying Party Agreement before the TAL will be emailed to you. To request the TAL after the production release, follow this link: http://www.arin.net/public/rpki/tal/index.xhtml; If a relying party's use of PKI infrastructure legally equated to acceptance of the relying party agreement (RPA), then having an explicit record of acceptance of the RPA would not be necessary. Alas, it does not appear possible to equate use of PKI certificates with agreement to the associated RPA (and some might argue that this is a feature, as some folks would not want to be legally bound to an agreement which they did not explicitly review and accept.) FYI, /John
Re: The End-To-End Internet (was Re: Blocking MX query)
On Thursday 06 September 2012 14:01:50 Masataka Ohta wrote: All that necessary is local changes on end systems of those who want the end to end transparency. There is no changes on the Internet. You're basically redefining the term end-to-end transparency to suit your own agenda. Globally implementing what is basically an application layer protocol in order to facilitate the functioning of an upper layer protocol (i.e. IPv4) is patent nonsense. The purpose of each layer is to facilitate the one it encapsulates, not the other way around. What you advocate is not end-to-end transparency but point-to-point opacity hinging on a morass of hacks that constitute little more than an abuse of existing technologies in an attempt to fulfil an unscalable goal. Fortunately, it is exactly that fact which makes all of your drafts and belligerent evangelising utterly pointless; you can continue to make noise and attempt to argue by redefinition all you like, the world will continue to forge ahead with the deployment of IPv6 and the *actual* meaning of the end-to-end principle will remain as it is. Regards, Oliver
Re: RPKI Pilot Participant Notice
On Thu, Sep 6, 2012 at 5:37 AM, John Curran jcur...@arin.net wrote: If a relying party's use of PKI infrastructure legally equated to acceptance of the relying party agreement (RPA), then having an explicit record of acceptance of the RPA would not be necessary. Alas, it does not appear possible to equate use of PKI certificates with agreement to the associated RPA (and some might argue that this is a feature, as some folks would not want to be legally bound to an agreement which they did not explicitly review and accept.) John, Randy: I'm confused. Are you saying that unlike a whois lookup, I'll need a contract with ARIN to look up and validate someone else's RPKI certificate? Would you clarify which parts of RPKI I need a contract with ARIN to do and which parts I do not? Thanks, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
dot1q encapsulation overhead?
A while back we had a customer colocated vpn router (2911) come in and we put it on our main vlan for initial set up and testing. Once that was done, I created a separate VLAN for them and a dot1q subinterface on an older, somewhat overloaded 2811. I set up the IPSec Tunnel, a /30 for each end to have an IP and all the static routes needed to make this work and it did. However, a few days later they were complaining of slow speeds...I don't recall, but maybe something like 5mbs when they needed 20 or so. We had no policing on that port. After a lot of testing, we tried putting them back on the main, native vlan and it worked fine...they got the throughput they needed. So my question is: could the dot1q encapsulation be causing throughput issues on a 2811 that's already doing a lot? I regret that I don't recall what sh proc cpu output was, or if I even ran it at all. It was kind of hectic just to get it fixed at the time. Well, a few months later (last week), the chicken came home to roost when their IPSec tunnel started proxy ARP puking stuff to our side that temporarily took out parts of our internal LAN. I have requested a 2911 replacement for the 2811 because I have seen the 2811 cpu load max out a few times when passing lots of traffic. I am hoping it will allow us to go back to this VLAN setup again, but I've never heard whether dot1q adds any overhead.
Re: The End-To-End Internet (was Re: Blocking MX query)
On Wed, Sep 05, 2012 at 09:39:44PM -0700, Owen DeLong wrote: Never mind the fact that all the hosts trying to reach you have no way to know what port to use. Despite my scepticism of the overall project, I find the above claim a little hard to accept. RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? Best, A -- Andrew Sullivan Dyn Labs asulli...@dyn.com
Re: dot1q encapsulation overhead?
On Thu, Sep 6, 2012 at 7:55 AM, u...@3.am wrote: A while back we had a customer colocated vpn router (2911) come in and we put it on our main vlan for initial set up and testing. Once that was done, I created a separate VLAN for them and a dot1q subinterface on an older, somewhat overloaded 2811. I set up the IPSec Tunnel, a /30 for each end to have an IP and all the static routes needed to make this work and it did. However, a few days later they were complaining of slow speeds...I don't recall, but maybe something like 5mbs when they needed 20 or so. We had no policing on that port. After a lot of testing, we tried putting them back on the main, native vlan and it worked fine...they got the throughput they needed. So my question is: could the dot1q encapsulation be causing throughput issues on a 2811 that's already doing a lot? I regret that I don't recall what sh proc cpu output was, or if I even ran it at all. It was kind of hectic just to get it fixed at the time. Well, a few months later (last week), the chicken came home to roost when their IPSec tunnel started proxy ARP puking stuff to our side that temporarily took out parts of our internal LAN. I have requested a 2911 replacement for the 2811 because I have seen the 2811 cpu load max out a few times when passing lots of traffic. I am hoping it will allow us to go back to this VLAN setup again, but I've never heard whether dot1q adds any overhead. It's small, but plain 802.1Q adds in a 4-byte (32-bit) header after the normal Ethernet header and before the actual Ethernet payload. That tag has to go somewhere. :p Also, I'm not privy to the details of your IPSec Tunnel, but that can introduce additional overhead as well. I'm not sure about your specific 2811/2911 and IOS combination (to know if this feature is there or not), but you might also consider setting ip tcp adjust-mss and ip mtu values on your tunnel interfaces to signal the true maximum-transportable-size of the various traffic types over the tunnel. I've also been bit by this bug before (http://networknerd.wordpress.com/2010/06/11/cisco-ipsec-mtu-bug/) that affects the MTU calculations of tunnels, for which the source address is specified by an interface, after a reboot. Worth knowing about. Cheers, jof
Are people still building SONET networks from scratch?
We've run into an issue with a customer that has been confounding us for a few months as we try to design what they need. The customer has a location in the relative middle of nowhere that they are trying to build a protected OC3 to. Ultimately, their traffic on it will be packet data (IP/ethernet, not channelized/voice). But they seem to be absolutely 100% set on the idea that they build with Cisco ONS boxes and that they run and control the D1-D12 bytes in order to manage protection switching on the OC3 (and have their DCC channel for management). Since this is the middle of nowhere, we are having to piece it together from a few runs of dark fiber here and there and lit services from about 3 other providers to get from the desired point A to the desired point B. The issues we seem to be hitting are: -We seem to be unable to find anyone who sells lit OC3 with D1-D12 transparency for the client. Sometimes we can get D1-D3, but that's it. -lit OC3/12/48 is ridiculously expensive comapred to 1g ethernet waves or 10g waves (choice LAN/WAN ethernet or OC192) 10g waves are cheap enough that we have entertained the idea of buying them and putting OC-192/muxponders on the ends to provide the OC-3, but even then I'm having trouble finding boxes that will do D1-D12 transparency for client OC-3. Building the whole thing on dark fiber so that we could specify the exact equipment on every hop isn't going to happen, as the protect path is about 1000 miles and the geography is such that we don't really have a market for all the other wasted capacity there would be on that path. Having much more experience with ethernet/packet/MPLS setups, we are trying to get the client to admit that 1g/10g waves running ethernet with QoS would be as good as or better in terms of latency, jitter, and loss for their packet data. So far they will barely listen to the arguments. And then going the next leap and showing them that we could work towards 50ms protection switching with MPLS/BFD/etc packet-based protocols is another stretch. Am I missing something here that my customer isn't, or is it the other way around? -Will
Re: Are people still building SONET networks from scratch?
On the surface this makes me want to cry. I could be missing something as well. On Thu, Sep 6, 2012 at 12:38 PM, Will Orton w...@loopfree.net wrote: We've run into an issue with a customer that has been confounding us for a few months as we try to design what they need. The customer has a location in the relative middle of nowhere that they are trying to build a protected OC3 to. Ultimately, their traffic on it will be packet data (IP/ethernet, not channelized/voice). But they seem to be absolutely 100% set on the idea that they build with Cisco ONS boxes and that they run and control the D1-D12 bytes in order to manage protection switching on the OC3 (and have their DCC channel for management). Since this is the middle of nowhere, we are having to piece it together from a few runs of dark fiber here and there and lit services from about 3 other providers to get from the desired point A to the desired point B. The issues we seem to be hitting are: -We seem to be unable to find anyone who sells lit OC3 with D1-D12 transparency for the client. Sometimes we can get D1-D3, but that's it. -lit OC3/12/48 is ridiculously expensive comapred to 1g ethernet waves or 10g waves (choice LAN/WAN ethernet or OC192) 10g waves are cheap enough that we have entertained the idea of buying them and putting OC-192/muxponders on the ends to provide the OC-3, but even then I'm having trouble finding boxes that will do D1-D12 transparency for client OC-3. Building the whole thing on dark fiber so that we could specify the exact equipment on every hop isn't going to happen, as the protect path is about 1000 miles and the geography is such that we don't really have a market for all the other wasted capacity there would be on that path. Having much more experience with ethernet/packet/MPLS setups, we are trying to get the client to admit that 1g/10g waves running ethernet with QoS would be as good as or better in terms of latency, jitter, and loss for their packet data. So far they will barely listen to the arguments. And then going the next leap and showing them that we could work towards 50ms protection switching with MPLS/BFD/etc packet-based protocols is another stretch. Am I missing something here that my customer isn't, or is it the other way around? -Will
Re: Are people still building SONET networks from scratch?
On 06/09/2012 17:38, Will Orton wrote: The customer has a location in the relative middle of nowhere that they are trying to build a protected OC3 to. Not sure if I see the problem here. Show them the bill for an OC3 service, and then show them the bill for the equivalent ethernet service. This usually works for me. If they want to pay for OC3 when there's no compelling reason to, who are you to argue? Nick
Re: The End-To-End Internet (was Re: Blocking MX query)
On Thu, Sep 6, 2012 at 11:14 AM, Andrew Sullivan asulli...@dyn.com wrote: RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? Hi Andrew, Because the developer of the next killer app knows exactly squat about the DNS and won't discover anything about the DNS that can't be had via getaddrinfo() until long after its too late redefine the protocol in terms of seeking SRV records. Leaving SRV out of getaddrinfo() means that SRVs will be no more than lightly used for the duration of the current networking API. The last iteration of the API survived around 20 years of mainstream use so this one probably has another 15 to go. Also there are efficiency issues associated with seeking SRVs first and then addresses, the same kind of efficiency issues with reverse lookups that lead high volume software like web servers to not do reverse lookups. But those pale in comparison to the first problem. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: The End-To-End Internet (was Re: Blocking MX query)
On Thu, Sep 06, 2012 at 01:49:06PM -0400, William Herrin wrote: the DNS and won't discover anything about the DNS that can't be had via getaddrinfo() until long after its too late redefine the protocol in terms of seeking SRV records. Oh, sure, I get that. One of the problems I've had with the end to end NAT argument is exactly that I can't see how it's any more deployable than IPv6, for exactly this reason. But the claim upthread was (I thought) that the application _can't_ know about this stuff, not that it's hard today. Because of the 20-year problem, I think now would be an excellent time to start thinking about how to make usable all those nice features we already have in the DNS. Maybe by the time I die, we'll have a useful system! Best, Andrew living in constant, foolish, failed hope Sullivan -- Andrew Sullivan Dyn Labs asulli...@dyn.com
Re: Are people still building SONET networks from scratch?
On Thu, Sep 6, 2012 at 1:00 PM, Nick Hilliard n...@foobar.org wrote: On 06/09/2012 17:38, Will Orton wrote: The customer has a location in the relative middle of nowhere that they are trying to build a protected OC3 to. Not sure if I see the problem here. Show them the bill for an OC3 service, and then show them the bill for the equivalent ethernet service. This usually works for me. If they want to pay for OC3 when there's no compelling reason to, who are you to argue? (remember, of course, to pad that bill by 8% so you profit more on the more expensive link... go telecom think!)
Re: Are people still building SONET networks from scratch?
On Thu, Sep 06, 2012 at 06:00:37PM +0100, Nick Hilliard wrote: Not sure if I see the problem here. Show them the bill for an OC3 service, and then show them the bill for the equivalent ethernet service. This usually works for me. If they want to pay for OC3 when there's no compelling reason to, who are you to argue? Nick Yes, of course the response is, figure out how to make the OC3 cheaper. :) So we're rapidly approaching a response of you've engineered yourself into a corner, take it or leave it. I just can't see how to get OC3 D1-D12 tunneled through without doing it as a mix of OC-48 and dark fiber for the entire path and specifying lots of complicated boxes just to get those bytes through. That cost is an order of magnitude more than just buying OC3 from multiple carriers (who can't tunnel D1-D12), which is a magnitude more than buying mpls-based gig-e or gig-e wave. I wasn't around (well, I was just a T1/DS3 customer) when all the OC3/12/48 SONET networks were built 10-15 years ago. I suppose they were all built directly on the fiber (maybe with WDM but no layer1.5-2 muxing) and the provider was always the one who handled protection switching? I've considered using J's PE-4CHOC3-CE-SFP (OC3 emulated SAToP), then I could do it all with gig-e underneath. Does anyone make a cheaper OC3 circuit emulation module or box? Most likely the customer wouldn't believe such a thing is possible and we'd have to put something in the contract allowing them SLA credit if their OC3 suffers too many timing slips or something. -Will
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 6, 2012, at 08:14 , Andrew Sullivan asulli...@dyn.com wrote: On Wed, Sep 05, 2012 at 09:39:44PM -0700, Owen DeLong wrote: Never mind the fact that all the hosts trying to reach you have no way to know what port to use. Despite my scepticism of the overall project, I find the above claim a little hard to accept. RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? If browsers started implementing it, it could. I suppose the more accurate/detailed statement would be: Without modifying every client on the internet, there is no way for the clients trying to reach you to reliably be informed of this port number situation. If you're going to touch every client, it's easier to just do IPv6. Owen
CLEC's in Ottawa area?
Hello, I have a client in the ottawa ontario canada area who is looking at DSL for a secondary connection. I am pretty unfamiliar with the state of telecom industry in Canada, I googled around and found this rather lengthy list of CLEC's. http://support.crtc.gc.ca/tlcmlsts/default.aspx?indx=33lang=e Does anyone have any good experiences with any of these carriers that service the Ottawa they could share? Also would be an added plus if they supported MLPPP as the client mentioned they were concerned with the lower speeds of DSL, so we would love to do two circuits with MLPPP if possible thanks! chris
Re: CLEC's in Ottawa area?
I recommend TekSavvy (www.teksavvy.com) as a DSL reseller pretty much anywhere in Ontario (and any other provinces they can get service in). Not sure why they're not on that CLEC list, but they're a pretty big (and awesome) provider up here. For bonus points, if you have to call their support line, you get someone who actually knows something about networking. We have some DSL lines through them at work, and my personal home cable connection is through them as well. - Pete On 12-09-06 02:33 PM, chris wrote: Hello, I have a client in the ottawa ontario canada area who is looking at DSL for a secondary connection. I am pretty unfamiliar with the state of telecom industry in Canada, I googled around and found this rather lengthy list of CLEC's. http://support.crtc.gc.ca/tlcmlsts/default.aspx?indx=33lang=e Does anyone have any good experiences with any of these carriers that service the Ottawa they could share? Also would be an added plus if they supported MLPPP as the client mentioned they were concerned with the lower speeds of DSL, so we would love to do two circuits with MLPPP if possible thanks! chris
Re: The End-To-End Internet (was Re: Blocking MX query)
On Thu, 06 Sep 2012 11:14:58 -0400, Andrew Sullivan said: Despite my scepticism of the overall project, I find the above claim a little hard to accept. RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? My PS3 may want to talk to the world, but I have no control over Comcast's DNS. pgprKXFEYZ1RQ.pgp Description: PGP signature
Re: Are people still building SONET networks from scratch?
On Thu, Sep 6, 2012 at 2:12 PM, Will Orton w...@loopfree.net wrote: . I suppose they were all built directly on the fiber (maybe with WDM but no layer1.5-2 muxing) and the provider was always the one who handled protection switching? or protection at the optical layer isn't as predictable for all aspects as L3 'protection' is... or something.
Re: The End-To-End Internet (was Re: Blocking MX query)
It would be really nice if people making statements about the end to end principle would talk about the end to end principle. http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf The abstract of the paper states the principle: This paper presents a design principle that helps guide placement of functions among the modules of a distributed computer system. The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level. Examples discussed in the paper include bit error recovery, security using encryption, duplicate message suppression, recovery from system crashes, and delivery acknowledgement. Low level mechanisms to support these functions are justified only as performance enhancements. One of the authors of the paper has since restated it in a way that is significantly less useful, which is that the only place anything intelligent should be done in a network is in the end system. If you believe that argument, then WiFi networks should not retransmit lost packets (and as a result would become far less useful) and the Internet should not use routing protocols - it should only use source routing. So, yes, I think the Rise of the Stupid Network is a very interesting paper and site, but needs to be handled carefully. The argument argues for simplicity and transparency; when a function at a lower layer does something an upper layer - not just the application, but any respectively higher and lower layers - it can be difficult to debug the behavior. However, it is not a hard-and-fast the network should never do things that the end system doesn't expect; the paper makes it clear that there is a trade-off, and if the trade-off makes sense (retransmitting at the link layer in addition to the end to end retransmission in the case of WiFi) it doesn't preclude the behavior. It merely suggests that one think about such things (retransmitting in LAPB turned out to be a bad idea way back when). Complexities of various types are unavoidable; to quote a fourteenth century logician, a satisfactory syllogism contains no unnecessary complexity. Yes, I think that stateful network address translation violates the end to end principle. But it doesn't violate it because everyone can't talk with everyone directly; it violates it because a change is made in a packet that subverts an end system's intent and as a result randomly breaks things (for example, an ICMP packet-too-large response has to be specially handled by the NAT to make PMTU work). I would argue that a network-imposed policies like traffic filters violate the end to end principle no more than network-imposed routing (including not-routing) policies do. If you can't get somewhere or a given address isn't instantiated with a host, that's not particularly surprising. What might be surprising and difficult to diagnose would be something that sometimes allows packets through and sometimes doesn't without any clear reason. I suspect everyone on this list will agree that the KISS principle, aka end-to-end, is pretty important, and get irritated with vendors (cough) that push them towards complex solutions. A host directly sending mail to a remote MTA is not automatically a bad actor for any reason related to KISS. There are two issues, however, that you might think about. My employer tells me that they discard about 98% of email traffic headed to me; a study of my own email history says that the email from outside that passes that filter and which is what I expect to receive comes through less than 1000 immediate SMTP predecessors to the first Cisco MTA; running the same survey on my junk folder (which is only 30 days, not 18 years) has about 5000 SMTP predecessors, the 1000 and the 5000 are disjoint sets. So an SMTP connection to a remote MTA is not a bad thing automatically, but it raises security eyebrows - and should - because it is similar to how spam and other attacks are transmitted. In addition, at least historically, in many cases those MUAs directly connecting to remote MTAs try or tried to use them as open relays, and it was difficult for the relay to authenticate random systems. Having an MUA give its traffic to a first hop MTA using SSL or some other form of service authentication/authorization improves the security of the service. That can be overcome using S/MIME, of course, given a global PKI, but DKIM depends on the premise that the originator has somehow been authenticated and shown to be authorized to send email. On Sep 4, 2012, at 11:22 AM, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com I am confused... I don't understand your comment. It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*,
Re: The End-To-End Internet (was Re: Blocking MX query)
In message 85250.1346959...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: --==_Exmh_1346959671_1993P Content-Type: text/plain; charset=us-ascii On Thu, 06 Sep 2012 11:14:58 -0400, Andrew Sullivan said: Despite my scepticism of the overall project, I find the above claim a little hard to accept. RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? My PS3 may want to talk to the world, but I have no control over Comcast's DNS. What point are you trying to make? Comcast's servers support SRV as do all general purpose name servers. For HTTP at least you need to be backwards compatible so there is no reason not to add SRV support. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iQIVAwUBUEj5NwdmEQWDXROgAQL/fRAAjHmAtVBMjQAybs2TWrzWMcE6e9k6A7Av LvOXJAS1leKr0tyg0lG4+IwuMCN5bV3+V8F7+bWAfQFSBIj9aH5ymSuxdO/LJVoj TdPRSRzTcPCL0mmIB5LbBdrDgi/PcruLdGDgOiLiLPhUkXnRJ+OmzR2WmAh4jgOz dVLb0ugujqbmqm7tzgxeiC0yzF9EiL3RQAZwzZI9Tcbnh0rELMHWBhgGeIO5KbA9 4iCh79MkrPXr4uONVQrCmbNBuqcziGIekKDGCpSUqwynzbc7NK00+Xhhkz2inNOn m7v73JFKzLd3AAjBenv3Yqz9hIwUGT4D9kW6Kof5Ah5SmzLY1ZOKpi+08M6i6SS/ I54neNmQ7lLuO9p7EsGpRTfUN1MOMEYXo8yOFTNQI7FDWCXNhWz/MjE3wxmXQYeA jBd8EE7m0QGuM6l/AhaS9BRXdZUXn8KK5E4N5YubJonLIuTzkTXuHmhFOB3Khlrl rHfl84sf8TdeDuxlJZs4PLdfRJooknNjSqLYfyfH0UeK3mSjlY3rpjcAZbSZsMdy vUDO0hU1C6FNFCXdkwRVZUtHxFX+l1sOtk76bt4s7NiWhwwGxwrykvk66qPa3YsH nyIWS7SsX245hy7dayKMKpYIByaAO6E7uVWzhgOobRMe3omP911BE30D2KYLXFvn wVqujobWuC4= =o0nz -END PGP SIGNATURE- --==_Exmh_1346959671_1993P-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
CAIDA's AS-rank project
Hello, We have been working on refreshing the data and algorithms behind CAIDA's as-rank project. We have published AS-relationships and AS-rankings computed for June 2012. We are currently seeking further validation of our rankings and relationship inferences. http://as-rank.caida.org/ The core of the algorithm is the inference of business relationships. Over the past two years we have received a significant amount of ground truth from operators through the corrections facility provided within AS-rank: in particular we obtained 1200 p2p relationships as a result of our previous algorithm that assigned many more customer/provider (c2p) relationships than ASes had in reality. Our intuition is that network owners are a lot more concerned when we infer a provider relationship that is actually a peer relationship, but are less motivated to validate other inferences. We have validated our algorithm against available ground truth and find our relationship inferences have a 99.1% positive predictive value (PPV) for c2p and 94.7% for p2p for the validation data we have available. Because customer cone computation depends on the accuracy of our c2p inferences, we are reasonably confident in our computed rankings. We are now soliciting further feedback in any shape and form offered. The as-rank website provides the ability for operators to submit corrections through the right-most corrections button on an individual ASes information page, and relationships ground-truth is solicited through that channel, if at all possible. Other feedback, on or off-list, would also be appreciated. If you are curious as to why a particular relationship was inferred, please get in contact with me. Some ASes have advised of a particular business relationship in the past, but when I drill down into the data it turns out they have a misconfiguration and are leaking routes to a peer. At a minimum, this might be a useful sanity check for some ASes who may be providing free transit without realising it. In the future, we plan to annotate each relationship with examples as to why it was inferred the way it was, but we have not yet got that far yet. Thanks, Matthew Luckie CAIDA
Re: CLEC's in Ottawa area?
On Thu, Sep 06, 2012 at 02:33:35PM -0400, chris wrote: Also would be an added plus if they supported MLPPP as the client mentioned they were concerned with the lower speeds of DSL, so we would love to do two circuits with MLPPP if possible I can second the recommendation of Teksavvy (http://teksavvy.com). I've been very happy with them, even though I sometimes have periods of painful outage due to the woeful shape of the copper plant in my neighbourhood. (Bell is sure not the company I knew growing up. Bureaucratic and monopolistic still, yes, but the wires are now in terrible shape.) Also, Teksavvy will do MLPPP. Look under add ons on the Teksavvy site. (e.g. http://teksavvy.com/en/residential/internet/dsl/high-speed-dsl-25). Looks like it's $4.00 a month. Note that, in some areas, there's no copper, so you need to check. Bell has been known to remove the copper where they installed their fibre to the customer premises. I think this is within the bounds of the CRTC rules, but I haven't been bothered to check. Note that in some markets, Teksavvy also offers service over cable, so that might be another option. (You said that it was for redundancy, though, so the cable might be in use already.) Best, A -- Andrew Sullivan Dyn Labs asulli...@dyn.com
Re: The End-To-End Internet (was Re: Blocking MX query)
On Fri, 07 Sep 2012 08:30:12 +1000, Mark Andrews said: In message 85250.1346959...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: My PS3 may want to talk to the world, but I have no control over Comcast's DNS. What point are you trying to make? Comcast's servers support SRV as do all general purpose name servers. For HTTP at least you need to be backwards compatible so there is no reason not to add SRV support. Sure, Comcast's servers will happily support an SRV entry for my PS3. However, Comcast's business processes don't support a way for me to request said SRV record be listed. Heck, I don't even get a static IP with my current service package. ;) Now *I* have the technical chops to talk to the guys at dyndns.org or other providers and get an SRV entry created under some domain name pointing back at my IP address. However, Joe Sixpack doesn't really have that option. And unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or whatever to request an SRV entry saying that the PS3 wants to do service foobar on port 34823, you can't use SRV like that. A better proposal would probably be having the NAT itself run a 'portmap' type service on a well known port like 111. Except that still doesn't do a very good job of disambiguating two instances of foobar behind a NAT... pgpAscas1weY8.pgp Description: PGP signature
