Re: Updated ARIN allocation information
* Owen DeLong In answer to Tore's statement, this block does not apply the standard justification criteria and I think you would actually be quite hard pressed to justify a /24 from this prefix. In most cases, it is expected that these would be the IPv4 address pool for the public facing IPv4 side of a NAT64 or 464xlat service. Most organizations probably only need one or two addresses and so would receive a /28. It is expected that each of these addresses likely supports several thousand customers in a service provider environment. This latter expectation of over-subscription is not echoed by the policy text itself. One of the valid usage examples mentioned («key dual stack DNS servers») would also be fundamentally incompatible with an requirement of over-subscription. If you look at the common transitional technologies you'll see that not even all of them do support over-subscription. In alphabetical order: - 6RD: No over-subscription possible, would require at least one IPv4 address per subscriber plus additional addressing required for the transport/access network. - 6PE/6VPE: No over-subscription possible, the infrastructure must be numbered normally with IPv4. - DS-Lite (AFTR): Over-subscription possible, but it's entirely reasonable to want to make the ratio as low as possible, in order to provide as many source ports as possible to the subscriber, to ease abuse handling, and so on. - MAP: Similar to DS-Lite, but is less flexible with regards to over-subscription, as all users in a MAP domain must get the same amount of ports. Thus the maximum over-subscription you can achieve is limited by your most active subscriber in his peak period of use, i.e., if you have a subscriber whose usage peaks to 20k ports, then that MAP domain can only support a 2:1 over-subscription ratio. MAP can also be configured in a not over-subscribed 1:1 mode. - NAT64: Same as DS-Lite. - SIIT: No over-subscription possible, as it's by design a 1:1 mapping. That said, the policy language does say «ARIN staff will use their discretion when evaluating justifications». So I suppose it is theoretically possible that the ARIN staff will do their best Dr. Evil impression, coming up with a big number N, and require requestors to have a N:1 over-subscription ratio to qualify. However, that would be better described as indiscretion, not discretion, IMHO. After all, the RIRs are book-keepers, not network operators; if a network operator makes a reasonable request, it isn't the RIR's place to second-guess their network deployment. If ARIN is doing that, they're overstepping. So in summary it seems to me that it is pretty easy to make a reasonable request for a /24 under this particular policy, and especially considering the immense routing benefit the /24 will have over all the other possible prefix lengths that can be requested (persuading providers/peers to accept /28s might be done on a small scale, but just won't work if you need global connectivity, and global connectivity is what end users expect), the only realistic outcome I can see is that [almost] all the requestors will go ahead and ask for the /24. We'll just have to wait and see, I guess. Tore
Re: Updated ARIN allocation information
While the policy text does not spell out a list of technologies, I believe that the clear intent of the community from the discussions and from the examples given in the policy text was for minimal IPv4 allocations to support the transition process. While no ratio is given in the policy text, I doubt that a “we have 200 customers wanting to do 6RD” would be accepted as justification for a /24. However, I am merely speculating here. I don’t have any direct answers from ARIN staff about how the policy would be interpreted. My statements are strictly my own personal interpretation of the community intent and an expression of my intent as the author of the policy. Owen On Feb 1, 2014, at 3:44 AM, Tore Anderson t...@fud.no wrote: * Owen DeLong In answer to Tore's statement, this block does not apply the standard justification criteria and I think you would actually be quite hard pressed to justify a /24 from this prefix. In most cases, it is expected that these would be the IPv4 address pool for the public facing IPv4 side of a NAT64 or 464xlat service. Most organizations probably only need one or two addresses and so would receive a /28. It is expected that each of these addresses likely supports several thousand customers in a service provider environment. This latter expectation of over-subscription is not echoed by the policy text itself. One of the valid usage examples mentioned («key dual stack DNS servers») would also be fundamentally incompatible with an requirement of over-subscription. If you look at the common transitional technologies you'll see that not even all of them do support over-subscription. In alphabetical order: - 6RD: No over-subscription possible, would require at least one IPv4 address per subscriber plus additional addressing required for the transport/access network. - 6PE/6VPE: No over-subscription possible, the infrastructure must be numbered normally with IPv4. - DS-Lite (AFTR): Over-subscription possible, but it's entirely reasonable to want to make the ratio as low as possible, in order to provide as many source ports as possible to the subscriber, to ease abuse handling, and so on. - MAP: Similar to DS-Lite, but is less flexible with regards to over-subscription, as all users in a MAP domain must get the same amount of ports. Thus the maximum over-subscription you can achieve is limited by your most active subscriber in his peak period of use, i.e., if you have a subscriber whose usage peaks to 20k ports, then that MAP domain can only support a 2:1 over-subscription ratio. MAP can also be configured in a not over-subscribed 1:1 mode. - NAT64: Same as DS-Lite. - SIIT: No over-subscription possible, as it's by design a 1:1 mapping. That said, the policy language does say «ARIN staff will use their discretion when evaluating justifications». So I suppose it is theoretically possible that the ARIN staff will do their best Dr. Evil impression, coming up with a big number N, and require requestors to have a N:1 over-subscription ratio to qualify. However, that would be better described as indiscretion, not discretion, IMHO. After all, the RIRs are book-keepers, not network operators; if a network operator makes a reasonable request, it isn't the RIR's place to second-guess their network deployment. If ARIN is doing that, they're overstepping. So in summary it seems to me that it is pretty easy to make a reasonable request for a /24 under this particular policy, and especially considering the immense routing benefit the /24 will have over all the other possible prefix lengths that can be requested (persuading providers/peers to accept /28s might be done on a small scale, but just won't work if you need global connectivity, and global connectivity is what end users expect), the only realistic outcome I can see is that [almost] all the requestors will go ahead and ask for the /24. We'll just have to wait and see, I guess. Tore
Re: Updated ARIN allocation information
On Feb 1, 2014, at 8:42 AM, Owen DeLong o...@delong.com wrote: While the policy text does not spell out a list of technologies, I believe that the clear intent of the community from the discussions and from the examples given in the policy text was for minimal IPv4 allocations to support the transition process. While no ratio is given in the policy text, I doubt that a “we have 200 customers wanting to do 6RD” would be accepted as justification for a /24. However, I am merely speculating here. I don’t have any direct answers from ARIN staff about how the policy would be interpreted. My statements are strictly my own personal interpretation of the community intent and an expression of my intent as the author of the policy. Owen - To be clear, ARIN is inclined to approve requests whenever it is possible to do such in compliance with policy. Given the leeway in the present policy text, we're likely to approve any reasonable request which is made under this policy, and it would not be difficult to imagine requests for /24 being approved as a result. If pooled use/oversubscription or specific technologies are required, it would be very helpful to provide additional policy text to staff. Thanks! /John John Curran President and CEO ARIN
Re: Level3 - Las Vegas - issues?
Hey, If you look in mylevel3.net you will be able to see any interruptions in Level3's net. /Peter 2014-01-31 Petter Bruland petter.brul...@allegiantair.com: Are there anyone from Level3 here, who can tell me if there are issues with Level3 in Las Vegas area? We're hosted out of the Switch SuperNAP, and we're having high packet loss on two different Internet circuits. And at 9:30 AM PST we had no connectivity to all our 70+ remote locations spread all over US on different carriers, from our VPN hub hosted on Level3 Any feedback is much appreciated, thanks! -Petter Petter Bruland | Network Engineer Allegiant Travel Company
Re: Is there such a thing as a 10GBase-T SFP+ transciever
That was the reason for the push to the 10x10 MSA by people like Google and other providers who did not want to use MM bundles and didn't want to deal with the expense and power consumption of 100GBase-LR4. LR10 although hasn't really seen much adoption by the vendors, only compatible optics from 3rd party vendors are available now. 40GBase-LR4 QSFP+ aren't really all that expensive these days. Gray market they are less than $2500. Cisco and Arista also just came out with 40G running over a single duplex MM fiber, 100M over OM3, and I expect the other datacenter vendors to follow suit shortly. As for 10GBase-T in a transceiver, I haven't seen that on anyone's roadmap. It will probably come eventually but not for awhile. -Phil On 1/31/14, 7:39 AM, Eric Clark cabe...@gmail.com wrote: What I want to see is reasonably priced 40G single mode transceivers. I have no idea why 40G and now 100G wasn't rolled out with single mode as the preference. The argument that there's a large multimode install base doesn't hold water. For one thing, you're using enormous amounts of MM fiber to get at best 1/4 of the ports than you previously had. The best case is that you could get 12 ports where you used to have 48, but that's messy. The second issue is cost, if you're running and distance, you've got to go to OM4, because MM fiber has very limited range at 10G (you're multiplexing 10G links), and OM4 is insanely expensive. Single Mode on the other hand is 'cheap' in comparison. One pair of SM fiber will handle every speed from 10M to 100G, and over much longer distances than MM, no matter what grade. Unfortunately, since the manufacturers haven't seen fit to push the SM, the optics are extremely expensive, so we're stuck with 4-12 times the amount of installed fiber than we really need. Grumble. On Jan 30, 2014, at 6:25 PM, Chris Balmain ch...@team.dcsi.net.au wrote: You may wish to consider twinax for short distance 10G over copper with SFP+ at both ends http://en.wikipedia.org/wiki/Twinaxial_cabling#SFP.2B_Direct-Attach_Coppe r_.2810GSFP.2BCu.29 Typically marketed as direct-attach (you can't remove the cables from the transceivers, it's all integrated) On 31/01/14 12:26, james jones wrote: I would like to know if anyone has seen one of these? If so where? Also if they don't exist why? It would seem to me that it would make it a lot easier to play mix and match with fiber in the DC if they did. Would be so hard to make the 1G SFPs faster (trying to be funny here not arrogant). -James
Re: Is there such a thing as a 10GBase-T SFP+ transciever
On Feb 1, 2014, at 4:05 PM, Phil Bedard bedard.p...@gmail.com wrote: As for 10GBase-T in a transceiver, I haven't seen that on anyone's roadmap. It will probably come eventually but not for awhile. It must exist, as there is this: http://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunderbolt-to-10-gbits-ethernet-desklink-device - Jared
Re: Is there such a thing as a 10GBase-T SFP+ transciever
Pluggable SFP+ transceiver. There are plenty of fixed config 10GBase-T devices out there. Power/space in a SFP+ package just isn't there yet. Phil On 2/1/14, 4:18 PM, Jared Mauch ja...@puck.nether.net wrote: On Feb 1, 2014, at 4:05 PM, Phil Bedard bedard.p...@gmail.com wrote: As for 10GBase-T in a transceiver, I haven't seen that on anyone's roadmap. It will probably come eventually but not for awhile. It must exist, as there is this: http://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunde rbolt-to-10-gbits-ethernet-desklink-device - Jared
Re: Is there such a thing as a 10GBase-T SFP+ transciever
On 2/1/14, 1:18 PM, Jared Mauch wrote: On Feb 1, 2014, at 4:05 PM, Phil Bedard bedard.p...@gmail.com wrote: As for 10GBase-T in a transceiver, I haven't seen that on anyone's roadmap. It will probably come eventually but not for awhile. It must exist, as there is this: Nah that's a 10G-base-t pci express nic in a box. which is fine and dandy for what it does but the phy doesn't fit in the power envelope or footprint of an sfp+ transciever. http://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunderbolt-to-10-gbits-ethernet-desklink-device - Jared signature.asc Description: OpenPGP digital signature
TWC (AS11351) blocking all NTP?
This evening all of my servers lost NTP sync, stating that our on-site NTP servers hadn't synced in too long. Reference time noted by the local NTP servers: Fri, Jan 31 2014 19:11:29.725 Apparently since then, NTP has been unable to traverse the circuit. Our other provider is shuffling NTP packets just fine, and after finding an NTP peer that return routed in that direction, I was able to get NTP back in shape. Spot checking various NTP peers configured on my end with various looking glasses close to the far-end confirm that anytime the return route is through AS11351, we never get the responses. Outbound routes almost always take the shorter route through our other provider. Is anyone else seeing this, or am I lucky enough to have it localized to my region (Northern NY)? I've created a ticket with the provider, although with it being the weekend, I have doubts it'll be a quick resolution. I'm sure its a strange knee-jerk response to the monlist garbage. Still, stopping time without warning is Uncool, Man. -- Jonathan Towne
Re: Is there such a thing as a 10GBase-T SFP+ transciever
IIRC, it takes about 13W to maintain a 10GBASET connection. That's a lot of power to drain from a tiny board that wasn't designed to supply such loads. ~tom On Saturday, February 1, 2014 1:32:58 PM, Phil Bedard bedard.p...@gmail.com wrote: Pluggable SFP+ transceiver. There are plenty of fixed config 10GBase-T devices out there. Power/space in a SFP+ package just isn't there yet. Phil On 2/1/14, 4:18 PM, Jared Mauch jared ja...@puck.nether.net@ja...@puck.nether.net puck.nether.net ja...@puck.nether.net wrote: On Feb 1, 2014, at 4:05 PM, Phil Bedard bedard.philbedard.p...@gmail.com @ bedard.p...@gmail.comgmail.com bedard.p...@gmail.com wrote: As for 10GBase-T in a transceiver, I haven't seen that on anyone's roadmap. It will probably come eventually but not for awhile. It must exist, as there is this: http://http://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunde store.apple.comhttp://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunde /us/product/HC294LL/A/http://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunde attohttp://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunde -http://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunde thunderlinkhttp://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunde -nt1102-http://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunde thundehttp://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunde rbolt-to-10-gbits-ethernet-desklink-device - Jared
Re: Is there such a thing as a 10GBase-T SFP+ transciever
+1. Cisco calls them Twinax, HP calls them DACs. I don't know what anyone else calls them as it hasn't come up in conversation for me. Cisco appears to offer them in 1, 1.5, 2, 2.5, 3, and 5 meter passive, as well as 7 and 10 meter active. HP has them in 1, 3, 7, 10, and 15 meter; no idea what the passive/active breakdown might be (they don't appear to offer that information as freely). I've mostly used the 3-meter HP DACs so far, and I've been rather happy with them, particularly the cost savings under 2x 10gbit SFP+ fiber transceivers. Jima On 2014-01-30 19:25, Chris Balmain wrote: You may wish to consider twinax for short distance 10G over copper with SFP+ at both ends http://en.wikipedia.org/wiki/Twinaxial_cabling#SFP.2B_Direct-Attach_Copper_.2810GSFP.2BCu.29 Typically marketed as direct-attach (you can't remove the cables from the transceivers, it's all integrated) On 31/01/14 12:26, james jones wrote: I would like to know if anyone has seen one of these? If so where? Also if they don't exist why? It would seem to me that it would make it a lot easier to play mix and match with fiber in the DC if they did. Would be so hard to make the 1G SFPs faster (trying to be funny here not arrogant). -James
Re: Is there such a thing as a 10GBase-T SFP+ transciever
On Sun, Feb 02, 2014 at 04:21:20AM +, Thomas Maufer wrote: IIRC, it takes about 13W to maintain a 10GBASET connection. That's a lot of power to drain from a tiny board that wasn't designed to supply such loads. ~tom On Saturday, February 1, 2014 1:32:58 PM, Phil Bedard bedard.p...@gmail.com wrote: Pluggable SFP+ transceiver. There are plenty of fixed config 10GBase-T devices out there. Power/space in a SFP+ package just isn't there yet. Phil Tom, I believe the newer 10GBase-T standard is between 1.5 and 4W per port depending on the cable length, much better (colder!) than it was. You will also get slightly increased latency with 10GBase-T vs SFP+ -- Bryan G. Seitz
