Re: SFP supplier in Europe?

2019-04-04 Thread nanog-isp
I'm just quoting what they state on their web pages. Not all models are in 
stock at their EU warehouses.

Jared

Sent: Friday, April 05, 2019
From: "Aled Morris" 
To: nanog-...@mail.com
Cc: fwessl...@succinctsystems.com, NANOG 
Subject: Re: SFP supplier in Europe?

On Thu, 4 Apr 2019 at 21:52, mailto:nanog-...@mail.com]> 
wrote:
Thanks to everybody that recommended Fiberstore and Flexoptics.

Unfortunately Fiberstore is what led me to ask about alternative suppliers. 
Fiberstore actually ships in their Bidi SFPs from Asia and lead times are one 
to two weeks. Flexoptics is actually worse with 4-6 weeks after ordering.
 
That's not been my experience with either of them.  
 
Aled


Re: SFP supplier in Europe?

2019-04-04 Thread Aled Morris via NANOG
On Thu, 4 Apr 2019 at 21:52,  wrote:

> Thanks to everybody that recommended Fiberstore and Flexoptics.
>
> Unfortunately Fiberstore is what led me to ask about alternative
> suppliers. Fiberstore actually ships in their Bidi SFPs from Asia and lead
> times are one to two weeks. Flexoptics is actually worse with 4-6 weeks
> after ordering.
>

That's not been my experience with either of them.

Aled


Re: SFP supplier in Europe?

2019-04-04 Thread Alfie Pates
That's weird, I've never had to wait for a Flexoptix order: Are you ordering 
pre-coded or are you coding them yourselves. Actually, I don't remember having 
to wait very long the last time I ordered a bunch of fs.com optics. 

~a


RE: Purchasing IPv4 space - due diligence homework

2019-04-04 Thread Torres, Matt via NANOG
Thanks NANOG. For those interested, here is a summary list of due diligence 
tasks for purchasing IPv4 on the secondary market:

  1.  Check out the seller (Google search). What is their story? Generally 
avoid hosting companies because they may have more block/black list cleanup to 
do.
  2.  Check the BGP looking glass Internet routing table. Make sure the IPv4 
address is not routed right now.
  3.  Check the historical Internet routing table. It is a good sign if the 
IPv4 network was advertised from the right company/ASN without recent changes 
https://stat.ripe.net/widget/routing-history#
  4.  Check ARIN registration. Singular, long standing registration for the 
IPv4 space is a good sign.
  5.  Check block list / black list. SORBS and Spamhaus are good resources. It 
is a good sign if the IPv4 network does not show up at all. 
http://www.anti-abuse.org/multi-rbl-check/
  6.  Check geo-location. It is a good sign if the IPv4 space shows up in the 
right global region. Try MaxMind.
  7.  There is a PowerShell script (that can be expanded on) to help expedite 
the checking process. 
https://www.saotn.org/powershell-blacklist-check-script/#more-2459

Thanks,
Matt




Re: SFP supplier in Europe?

2019-04-04 Thread nanog-isp
Thanks to everybody that recommended Fiberstore and Flexoptics.

Unfortunately Fiberstore is what led me to ask about alternative suppliers. 
Fiberstore actually ships in their Bidi SFPs from Asia and lead times are one 
to two weeks. Flexoptics is actually worse with 4-6 weeks after ordering.

Jared

> Sent: Thursday, April 04, 2019
> From: fwessl...@succinctsystems.com
> To: nanog@nanog.org, mike.l...@gmail.com, "i3D.net - Martijn Schmidt" 
> 
> Cc: "nanog@nanog.org" , "nanog-...@mail.com" 
> 
> Subject: Re: SFP supplier in Europe?
>
>  fs.com for sure
>
> On April 4, 2019 4:38:07 PM EDT, mike.l...@gmail.com wrote:
> >May want to try fs.com.
> >
> >https://www.fs.com/company/about_us.html
> >
> >I use their optics and am quite happy with them.
> >
> >-Mike
> >
> >> On Apr 4, 2019, at 13:19, i3D.net - Martijn Schmidt
> > wrote:
> >>
> >> You'll want to have a talk with FlexOptix, they're based in Germany
> >and you can live view the stock in their local warehouse on the
> >website, without even logging in. They've got a great team too!
> >>
> >>> On 4 April 2019 23:09:15 EEST, nanog-...@mail.com wrote:
> >>> Hello NANOG,
> >>>
> >>> Could somebody recommend an SFP supplier in Europe with a warehouse
> >in the EU and fast shipping? I need to pick up some 80km Bidi SFPs and
> >I'd prefer to use a supplier has and will keep stock locally.
> >>>
> >>> Jared
> >>
> >> --
> >> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> Frederick Wessling (CIO)
> Succinct Systems LLC
> Cell: +1(561) 571-2799
> Office: +1(904) 758-9915 ext. 9925
> Fax: +1(904) 758-9987
> www.SuccinctSystems.com
>


Re: SFP supplier in Europe?

2019-04-04 Thread nanog
I highly recommends https://www.alturnanetworks.com/

They sell solid optics, all are tested
Quick shipping, competitive price

I have never been even remotely disappointed with those guys


On 04/04/2019 10:09 PM, nanog-...@mail.com wrote:
> Hello NANOG,
> 
> Could somebody recommend an SFP supplier in Europe with a warehouse in the EU 
> and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer to 
> use a supplier has and will keep stock locally.
> 
> Jared
> 



Re: SFP supplier in Europe?

2019-04-04 Thread mike . lyon
May want to try fs.com. 

https://www.fs.com/company/about_us.html

I use their optics and am quite happy with them.

-Mike

> On Apr 4, 2019, at 13:19, i3D.net - Martijn Schmidt  
> wrote:
> 
> You'll want to have a talk with FlexOptix, they're based in Germany and you 
> can live view the stock in their local warehouse on the website, without even 
> logging in. They've got a great team too! 
> 
>> On 4 April 2019 23:09:15 EEST, nanog-...@mail.com wrote:
>> Hello NANOG,
>> 
>> Could somebody recommend an SFP supplier in Europe with a warehouse in the 
>> EU and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer 
>> to use a supplier has and will keep stock locally.
>> 
>> Jared
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: SFP supplier in Europe?

2019-04-04 Thread i3D . net - Martijn Schmidt
You'll want to have a talk with FlexOptix, they're based in Germany and you can 
live view the stock in their local warehouse on the website, without even 
logging in. They've got a great team too!

On 4 April 2019 23:09:15 EEST, nanog-...@mail.com wrote:

Hello NANOG,

Could somebody recommend an SFP supplier in Europe with a warehouse in the EU 
and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer to use 
a supplier has and will keep stock locally.

Jared

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: SFP supplier in Europe?

2019-04-04 Thread Alfie Pates
Can't reccomend Flexoptix[1] enough. Great service, fast shipping, and you only 
need to maintain one stock of optics even if you use kit from different 
vendors. 

FS.com are the go-to for bulk purchases of pre-coded optics on a budget: a few 
more cot deaths than most, but they're cheap and in my experience work reliably 
enough. 

[1] https://www.flexoptix.net/en/

~a 


Re: SFP supplier in Europe?

2019-04-04 Thread David Hubbard
Flexoptix may be an option; they're Germany.  Even US shipping is typically two 
day.

On 4/4/19, 4:10 PM, "NANOG on behalf of nanog-...@mail.com" 
 wrote:

Hello NANOG,

Could somebody recommend an SFP supplier in Europe with a warehouse in the 
EU and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer to 
use a supplier has and will keep stock locally.

Jared




SFP supplier in Europe?

2019-04-04 Thread nanog-isp
Hello NANOG,

Could somebody recommend an SFP supplier in Europe with a warehouse in the EU 
and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer to use 
a supplier has and will keep stock locally.

Jared


RE: DNS Qtypes and class values are a social construct

2019-04-04 Thread Phillip Carroll
#Alfie-is-triggered

From: NANOG  On Behalf Of Alfie Pates
Sent: Monday, April 1, 2019 11:08 AM
To: Mankamana Mishra (mankamis) via NANOG 
Subject: Re: DNS Qtypes and class values are a social construct

I feel this comes off as poking fun at trans people, women, and earnest 
attempts to combat what are actual problems in our industry, more than it pokes 
fun at the industry itself which is what a good April Fool should do - this 
feels more like laughing at "outsiders" more than laughing at ourselves.

I think this is pretty tone-deaf, in my opinion.

~a


RE: modeling residential subscriber bandwidth demand

2019-04-04 Thread John DAmbrosia
All,
I am chairing an effort in the IEEE 802.3 Ethernet Working Group to understand 
bandwidth demand and how it will impact future Ethernet needs.  This is exactly 
the type of discussion i would like to get shared with this activity.  I would 
appreciate follow-on conversations with anyone wishing to share their 
observations.

Regards,

John D'Ambrosia
Chair, IEEE 802.3 New Ethernet Applications Ad hoc

-Original Message-
From: NANOG  On Behalf Of James Bensley
Sent: Thursday, April 4, 2019 4:41 AM
To: Tom Ammon ; NANOG 
Subject: Re: modeling residential subscriber bandwidth demand

On Tue, 2 Apr 2019 at 17:57, Tom Ammon  wrote:
>
> How do people model and try to project residential subscriber bandwidth 
> demands into the future? Do you base it primarily on historical data? Are 
> there more sophisticated approaches that you use to figure out how much 
> backbone bandwidth you need to build to keep your eyeballs happy?
>
> Netflow for historical data is great, but I guess what I am really asking is 
> - how do you anticipate the load that your eyeballs are going to bring to 
> your network, especially in the face of transport tweaks such as QUIC and TCP 
> BBR?
>
> Tom

Hi Tom,

Historical data is definitely the way to predict a trend, you can’t call 
something a trend if it only started today IMO, something (e.g.
bandwidth profiling) needs to have been recorded for a while before you can say 
that you are trying to predict the trend. Without historical data you're just 
making predications without any direction, which I don't think you want J

Assuming you have a good mixture of subs, i.e. adults, children, male, female, 
different regions etc. and 100% of your subs aren't a single demographic like 
university campuses for example; then I don't think you need to worry about 
specifics like the adoption of QUIC or BBR.
You will never see a permeant AND massive increase in your total aggregate 
network utilisation from one day to the next.

If for example, a large CDN makes a change that increases per-user bandwidth 
requirements, it's unlikely they are going to deploy it globally in one single 
big-bang change. This would also be just one of your major bandwidth 
sources/destinations, of which you'll likely have several big-hitters that make 
up the bulk of your traffic. If you have planned well so far, and have plenty 
of spare capacity (as others have mentioned, in the 50-70% range and your 
backhaul/peering/transit links are of a reasonable size ratio to your subs, 
e.g. subs get 10-20Mbps services and your links are 1Gbps) there should be no 
persisting risk to your network capacity as long as you keep following the same 
upgrade trajectory. Major social events like the Super Bowl where you are (or 
here in England, sunshine) will cause exceptional traffic increases, but only 
for brief periods.

You haven't mentioned exactly what you're doing for modelling capacity demand 
(assuming that you wanted feedback on it)?

Assuming all the above is true for you, to give us a reasonable foundation to 
build on; In my experience the standard method is to record your ingress 
traffic rate at all your PEs or P nodes, and essentially divide this by the 
number of subs you have (egress is important too, it's just usually negligible 
in comparison). For example, if your ASN has a total average ingress traffic 
rate of 1Gbps at during peak hours and, you have 10,000 subs, you can model on 
say 0.1Mbps per sub. That’s actually a crazily low figure these days but, it’s 
just a fictional example to demonstrate the calculation.

The ideal scenario is that you have this info for as long as you can.
Also, the more subs you have the better it all averages out. For business ISPs, 
bringing on 1 new customer can make a major difference, if it’s a 100Gbps 
end-site site and your backbone is a single 100Gbps link you could be in 
trouble. For residential services, subs almost always have slower links than 
your backbone/P/PE nodes.

If you have different types of subs it’s also worth breaking down the stats by 
sub type. For example; we have ADSL subs and VDSL subs. We record the egress 
traffic rate on the BNGs towards each type of sub separately and then aggregate 
across all BNGs. For example, today peak inbound for our ASN was X, of that X, 
Y went to ADSL subs and Z when to VDSL subs. Y / $number_of_adsl_subs == peak 
average for an ADSL line and, Z / $number_of_vdsl_subs == peak average for a 
VDSL line.

It’s good to know this difference because a sub migrating from ADSL to VDSL is 
not the same as getting a new sub in terms of additional traffic growth. We 
have a lot of users upgrading to VDSL which makes a difference at scale, e.g 
10K upgrades is less additional traffic than 10k new subs. Rinse and repeat for 
you other customer types (FTTP/H, wireless etc.)


> On Tue, Apr 2, 2019 at 2:20 PM Josh Luthman  
> wrote:
>>
>> We have GB/mo figures for our customers for every month for the last ~10 
>> 

Re: GPS WNRO April 6th at GPS Midnight

2019-04-04 Thread Stephen Satchell
On 4/3/19 3:32 PM, brutal8z via NANOG wrote:
> I've not seen any mention of this here, so it might be off-topic, if so,
> sorry in advance. If you use GPS for time synchronization, this might be
> important.The Juniper ACX500 series and the Cisco 819 both have an
> embedded GPS receivers, for example.
> 
> At 23:59:42 UTC on 4/6/2019 (Midnight GPS time, which differs by 18
> leap-seconds  from UTC) , the
> 10-bit GPS Week Number broadcast by the constellation will reset to zero
> for the second time since the beginning of GPS on 1/6/1980.

There was a mention of this a couple of weeks ago, as a "heads-up".

When it first appeared up here, I checked with the vendor of my GPS time
appliances.  The vendor told me that the testing they did of their
product showed no issues with the roll-over for specific ranges of
serial numbers.  Mine is within one of the ranges.

The proof of the pudding will be what happens at 5pm PDT on my birthday,
April 6, and what ntpq reports on my edge server.



GPS WNRO April 6th at GPS Midnight

2019-04-04 Thread brutal8z via NANOG
I've not seen any mention of this here, so it might be off-topic, if so, 
sorry in advance. If you use GPS for time synchronization, this might be 
important.The Juniper ACX500 series and the Cisco 819 both have an 
embedded GPS receivers, for example.


At 23:59:42 UTC on 4/6/2019 (Midnight GPS time, which differs by 18 
leap-seconds  from UTC) , the 
10-bit GPS Week Number broadcast by the constellation will reset to zero 
for the second time since the beginning of GPS on 1/6/1980.


Ken

--
GPS Week Number Rollover (WNRO)



Re: modeling residential subscriber bandwidth demand

2019-04-04 Thread James Bensley
On Tue, 2 Apr 2019 at 17:57, Tom Ammon  wrote:
>
> How do people model and try to project residential subscriber bandwidth 
> demands into the future? Do you base it primarily on historical data? Are 
> there more sophisticated approaches that you use to figure out how much 
> backbone bandwidth you need to build to keep your eyeballs happy?
>
> Netflow for historical data is great, but I guess what I am really asking is 
> - how do you anticipate the load that your eyeballs are going to bring to 
> your network, especially in the face of transport tweaks such as QUIC and TCP 
> BBR?
>
> Tom

Hi Tom,

Historical data is definitely the way to predict a trend, you can’t
call something a trend if it only started today IMO, something (e.g.
bandwidth profiling) needs to have been recorded for a while before
you can say that you are trying to predict the trend. Without
historical data you're just making predications without any direction,
which I don't think you want J

Assuming you have a good mixture of subs, i.e. adults, children, male,
female, different regions etc. and 100% of your subs aren't a single
demographic like university campuses for example; then I don't think
you need to worry about specifics like the adoption of QUIC or BBR.
You will never see a permeant AND massive increase in your total
aggregate network utilisation from one day to the next.

If for example, a large CDN makes a change that increases per-user
bandwidth requirements, it's unlikely they are going to deploy it
globally in one single big-bang change. This would also be just one of
your major bandwidth sources/destinations, of which you'll likely have
several big-hitters that make up the bulk of your traffic. If you have
planned well so far, and have plenty of spare capacity (as others have
mentioned, in the 50-70% range and your backhaul/peering/transit links
are of a reasonable size ratio to your subs, e.g. subs get 10-20Mbps
services and your links are 1Gbps) there should be no persisting risk
to your network capacity as long as you keep following the same
upgrade trajectory. Major social events like the Super Bowl where you
are (or here in England, sunshine) will cause exceptional traffic
increases, but only for brief periods.

You haven't mentioned exactly what you're doing for modelling capacity
demand (assuming that you wanted feedback on it)?

Assuming all the above is true for you, to give us a reasonable
foundation to build on;
In my experience the standard method is to record your ingress traffic
rate at all your PEs or P nodes, and essentially divide this by the
number of subs you have (egress is important too, it's just usually
negligible in comparison). For example, if your ASN has a total
average ingress traffic rate of 1Gbps at during peak hours and, you
have 10,000 subs, you can model on say 0.1Mbps per sub. That’s
actually a crazily low figure these days but, it’s just a fictional
example to demonstrate the calculation.

The ideal scenario is that you have this info for as long as you can.
Also, the more subs you have the better it all averages out. For
business ISPs, bringing on 1 new customer can make a major difference,
if it’s a 100Gbps end-site site and your backbone is a single 100Gbps
link you could be in trouble. For residential services, subs almost
always have slower links than your backbone/P/PE nodes.

If you have different types of subs it’s also worth breaking down the
stats by sub type. For example; we have ADSL subs and VDSL subs. We
record the egress traffic rate on the BNGs towards each type of sub
separately and then aggregate across all BNGs. For example, today peak
inbound for our ASN was X, of that X, Y went to ADSL subs and Z when
to VDSL subs. Y / $number_of_adsl_subs == peak average for an ADSL
line and, Z / $number_of_vdsl_subs == peak average for a VDSL line.

It’s good to know this difference because a sub migrating from ADSL to
VDSL is not the same as getting a new sub in terms of additional
traffic growth. We have a lot of users upgrading to VDSL which makes a
difference at scale, e.g 10K upgrades is less additional traffic than
10k new subs. Rinse and repeat for you other customer types (FTTP/H,
wireless etc.)


> On Tue, Apr 2, 2019 at 2:20 PM Josh Luthman  
> wrote:
>>
>> We have GB/mo figures for our customers for every month for the last ~10 
>> years.  Is there some simple figure you're looking for?  I can tell you off 
>> hand that I remember we had accounts doing ~15 GB/mo and now we've got 1500 
>> GB/mo at similar rates per month.
>>
>
> I'm mostly just wondering what others do for this kind of planning - trying 
> to look outside of my own experience, so I don't miss something obvious. That 
> growth in total transfer that you mention is interesting.

You need to be careful with volumetric based usage figures. As links
continuously increase in speed over the years, users can transfer the
same amount of data in less bit-time. The problem with polling at any
interval (be it 1 

Re: Purchasing IPv4 space - due diligence homework

2019-04-04 Thread Marco Davids via NANOG

Op 04-04-19 om 01:14 schreef Mike Hammett:

Do you have sources for the ~90% T-Mobile IPv6? Not arguing, but to use 
that as a source myself when spreading the IPv6 good word.




https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png

https://stats.labs.apnic.net/ipv6/US (a bit slow, but informative)

--
Marco