Re: [EXTERNAL] Re: VoIP Provider DDoSes

[K. Scott Helms]

The problem with this approach, and with scrubbing centers more generally,
is that while the cure might be better than the disease it doesn't result
in usable VOIP.  Voice customers don't care if things are _better_ but
their MOS scores are still below 2.

Scott Helms



On Wed, Sep 22, 2021 at 11:58 AM Compton, Rich A 
wrote:

> FYI, UTRS (Unwanted Traffic Removal Service
> https://team-cymru.com/community-services/utrs/) from Team Cymru is a
> free service where you can send a blackhole advertisement (sacrificing the
> one IP that’s under attack to save the rest of the network) and they will
> propagate that via BGP to hundreds of other ASNs which will then blackhole
> traffic to that IP.  This can drastically reduce the amount of DDoS traffic
> that is received by the victim network.
>
>
>
> -Rich
>
>
>
> *From: *NANOG  on
> behalf of Mike Hammett 
> *Date: *Wednesday, September 22, 2021 at 9:29 AM
> *To: *Terrance Devor 
> *Cc: *NANOG list 
> *Subject: *[EXTERNAL] Re: VoIP Provider DDoSes
>
>
>
> *CAUTION:* The e-mail below is from an external source. Please exercise
> caution before opening attachments, clicking links, or following guidance.
>
> Fail2Ban on a couple of dozen servers may not be sufficient to address 400
> gigs of traffic.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
> --
>
> *From: *"Terrance Devor" 
> *To: *"Mike Hammett" 
> *Cc: *"NANOG" 
> *Sent: *Wednesday, September 22, 2021 10:24:07 AM
> *Subject: *Re: VoIP Provider DDoSes
>
> Fail2Ban and give ourselves a pat on the back..
>
>
>
> On Wed, Sep 22, 2021 at 9:12 AM Mike Hammett  wrote:
>
> https://twit.tv/shows/security-now/episodes/837?autostart=false
>
>
>
>
>
> It looks like Security Now covered this yesterday. They claimed that,
> "There  is  currently  no  provider of  large  pipe  VoIP  protocol  DDoS
>  protection."
>
>
>
> Are any of the cloud DDoS mitigation services offering a service like this.
> --
>
> *From: *"Mike Hammett" 
> *To: *"NANOG" 
> *Sent: *Tuesday, September 21, 2021 4:19:42 PM
> *Subject: *VoIP Provider DDoSes
>
> As many may know, a particular VoIP supplier is suffering a DDoS.
> https://twitter.com/voipms
>
>
>
> Are your garden variety DDoS mitigation platforms or services equipped to
> handle DDoSes of VoIP services? What nuances does one have to be cognizant
> of? A WAF doesn't mean much to SIP, IAX2, RTP, etc.
>
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
>
>
> The contents of this e-mail message and
> any attachments are intended solely for the
> addressee(s) and may contain confidential
> and/or legally privileged information. If you
> are not the intended recipient of this message
> or if this message has been addressed to you
> in error, please immediately alert the sender
> by reply e-mail and then delete this message
> and any attachments. If you are not the
> intended recipient, you are notified that
> any use, dissemination, distribution, copying,
> or storage of this message or any attachment
> is strictly prohibited.
>

Re: EXTERNAL: Re: VoIP Provider DDoSes

[K. Scott Helms]

I'm going to be reaching out to both of the organizations you listed, but I
don't see any of their documentation mentioning SIP, RTP, or any of the
"normal" VOIP protocols or use cases.

Scott Helms



On Wed, Sep 22, 2021 at 9:18 AM Ray Orsini  wrote:

> Yes there are. I was about to message Steve about the correction. Corero
> and path.net are options. There are others.
> [image: OIT Website] <https://www.oit.co/>
> Ray Orsini​
> Chief Executive Officer
> OIT, LLC
>  *305.967.6756 x1009* <305.967.6756%20x1009>  |   *305.571.6272*
>  *r...@oit.co*   |  [image: https://www.oit.co]
> <https://www.oit.co/> * www.oit.co* <https://www.oit.co/>
>  oit.co/ray
> [image: Facebook] <https://go.oit.co/facebook>
> [image: LinkedIn] <https://go.oit.co/linkedin>
> [image: Twitter] <https://go.oit.co/twitter>
> [image: YouTube] <https://go.oit.co/youtube>
>
> *How are we doing? We'd love to hear your feedback. https://go.oit.co/review*
> <https://go.oit.co/review>
> --
> *From:* NANOG  on behalf of Mike
> Hammett 
> *Sent:* Wednesday, September 22, 2021 9:08:22 AM
> *To:* NANOG 
> *Subject:* EXTERNAL: Re: VoIP Provider DDoSes
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe. If you are unsure, please forward this email to the
> CSE team for review.
>
> https://twit.tv/shows/security-now/episodes/837?autostart=false
>
>
> It looks like Security Now covered this yesterday. They claimed that,
> "There  is  currently  no  provider of  large  pipe  VoIP  protocol  DDoS
>  protection."
>
> Are any of the cloud DDoS mitigation services offering a service like this.
>
> --
> *From: *"Mike Hammett" 
> *To: *"NANOG" 
> *Sent: *Tuesday, September 21, 2021 4:19:42 PM
> *Subject: *VoIP Provider DDoSes
>
> As many may know, a particular VoIP supplier is suffering a DDoS.
> https://twitter.com/voipms
>
> Are your garden variety DDoS mitigation platforms or services equipped to
> handle DDoSes of VoIP services? What nuances does one have to be cognizant
> of? A WAF doesn't mean much to SIP, IAX2, RTP, etc.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[K. Scott Helms]

On Fri, Jul 9, 2021 at 4:47 PM Michael Thomas  wrote:

>
> On 7/9/21 1:36 PM, K. Scott Helms wrote:
> > Nothing will change immediately.  Having said that, I do expect that
> > we will see much more effective enforcement. The investigations will
> > come from the ITG (Industry Traceback Group) with enforcement
> > coming from FCC or FTC depending on the actual offense.  The problem
> > has been that it's been far too easy for robocalling companies to hop
> > from one telecom provider to another.  Now there are requirements
> > around "know your customer" that telecom operators have to follow and
> > the ITG will have a much better chance of figuring out who the bad
> > actor is than they have in the past.
>
> The thing is that that shouldn't have been held up by rolling out STIR.
> With email, there was nothing akin to the FCC so it was really the only
> name-and-shame stick we had. This could have been done years ago.
>

It wouldn't work the same and I say that as someone who ran email for ISPs
for decades and just got done with a STIR/SHAKEN implementation.  There's
far more money in robocalls than there ever has been in spam.  The other
thing is that the technologies are fundamentally different.  Don't get me
wrong, there are parallels, but comparing email to the various flavors of
telephony (POTS, SIP, MGCP, H.323, etc) isn't all that useful because
they're so different.  When I get an email as a provider I can always
figure out the path it took to get to me.  The same is not at all true for
a call, though I can trace it to a degree via the CDRs from carriers I work
with.  Much of the call path will be opaque and often in the case of
robocallers it's intentionally so.  Number porting is another (big)
difference.  We could always choose to forward email for a customer who
left our service, but imagine if email literally let that person take their
address with them regardless of who was providing the hosting for the email.



> > Longer term I worry that this will lead to more attacks on PBXs,
> > eSBCs, and VOIP handsets to be able to call either from that endpoint
> > itself or be able to use the SIP credentials. The market for robocalls
> > will certainly not disappear.
> >
> A meta question that really needs to be asked these days is why we even
> need telco telephony anymore. A lot of problems go away if you are not
> in thrall to 100 year old technology and its accreted kruft.
>

Robocalls really aren't a product of the legacy PSTN.  Today almost none of
them originate from anywhere but VOIP.  Now, you can certainly say that if
SS7 had robust authentication mechanisms that we could then trust caller ID
(more) but there's no sign of us abandoning the PSTN anytime soon.  Having
said that, there's any number of protocols we rely on today that have the
exact same gap.  BGP is arguably even worse than SS7.

tl;dr You can no more get rid of telephone companies than you can get rid
of ISPs.



>
> Mike
>
>

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[K. Scott Helms]

Nothing will change immediately.  Having said that, I do expect that we
will see much more effective enforcement.  The investigations will come
from the ITG (Industry Traceback Group) with enforcement coming from FCC or
FTC depending on the actual offense.  The problem has been that it's been
far too easy for robocalling companies to hop from one telecom provider to
another.  Now there are requirements around "know your customer" that
telecom operators have to follow and the ITG will have a much better chance
of figuring out who the bad actor is than they have in the past.

Longer term I worry that this will lead to more attacks on PBXs, eSBCs, and
VOIP handsets to be able to call either from that endpoint itself or be
able to use the SIP credentials.  The market for robocalls will certainly
not disappear.

Scott Helms



On Fri, Jul 9, 2021 at 1:07 PM Michael Thomas  wrote:

> Nothing has changed for me either. Color me surprised. The real proof will
> be to see if the originating domain can be determined, and whether the
> receiving domain does anything about it.
>
> Mike
> On 7/9/21 9:42 AM, Brandon Svec via NANOG wrote:
>
> I’m getting the same or more, but did anyone really expect they would stop
> July 1? It will take time for complaints to be tracked down and operators
> to take actions, right?
>
> Brandon
>
> On Fri, Jul 9, 2021 at 6:49 AM Josh Luthman 
> wrote:
>
>> Subjectively speaking, I'm still getting the same amount of spam phone
>> calls.
>>
>> I'm certainly getting a lot more spam SMS to my cell.  Almost all of them
>> in my entire life starting July 1...
>>
>>
>> Josh Luthman
>> 24/7 Help Desk: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> <https://www.google.com/maps/search/1100+Wayne+St+Suite+1337+Troy,+OH+45373?entry=gmail=g>
>> Suite 1337
>> <https://www.google.com/maps/search/1100+Wayne+St+Suite+1337+Troy,+OH+45373?entry=gmail=g>
>> Troy, OH 45373
>> <https://www.google.com/maps/search/1100+Wayne+St+Suite+1337+Troy,+OH+45373?entry=gmail=g>
>>
>>
>> On Fri, Jul 9, 2021 at 9:40 AM Jeff Shultz 
>> wrote:
>>
>>> All I know is that I am getting a lot fewer bogus calls on my cell phone
>>> than I was this time last month.
>>>
>>> On Fri, Jul 9, 2021, 06:17 Ryan Finnesey via NANOG 
>>> wrote:
>>>
>>>> This should help with Robo calls a lot.
>>>>
>>>> -Original Message-
>>>> From: NANOG  On
>>>> Behalf Of Sean Donelan
>>>> Sent: Wednesday, June 30, 2021 2:31 PM
>>>> To: nanog@nanog.org
>>>> Subject: SITR/SHAKEN implementation in effect today (June 30 2021)
>>>>
>>>>
>>>> STIR/SHAKEN Broadly Implemented Starting Today
>>>> https://www.fcc.gov/document/stirshaken-broadly-implemented-starting-today
>>>>
>>>> WASHINGTON, June 30, 2021—FCC Acting Chairwoman Jessica Rosenworcel
>>>> today announced that the largest voice service providers are now using
>>>> STIR/SHAKEN caller ID authentication standards in their IP networks, in
>>>> accordance with the deadline set by the FCC. This widespread implementation
>>>> helps protect consumers against malicious spoofed robocalls and helps law
>>>> enforcement track bad actors. The STIR/SHAKEN standards serve as a common
>>>> digital language used by phone networks, allowing valid information to pass
>>>> from provider to provider which, among other things, informs blocking tools
>>>> of possible suspicious calls.
>>>
>>> --
> Brandon Svec
> 15106862204 ☎️ or 
>
>

Re: Email and Web Hosting

[K. Scott Helms]

Two decent options, one on prem and the other fully hosted.

Tucows/OpenSRS has a fully hosted email offering that was built for ISPs to
resell.  (They also have domain registration and some other ISP focused
services.)

https://opensrs.com/services/hosted-email/

MagicMail is an email (including webmail) suite that you run on prem.  It
is comparatively inexpensive but also fully supported.  It's built largely
on qmail, but they replaced some of the components to deal with spam and
virus filtering more efficiently.

https://www.magicmail.com/

I have direct experience with both and have used them both for ISPs
specifically.

Scott Helms



On Tue, Jul 6, 2021 at 10:44 AM Steve Saner  wrote:

> I hope this isn't too far off topic for this list.
>
> We acquired a small ISP a couple years ago that has its roots in the
> "local ISPs" of the 90s. This ISP is still hosting email and web services
> for customers both on company domains as well as customer domains. There is
> some decent revenue coming from these services, but cost of maintenance is
> becoming a challenge. We are looking at migrating to another platform or
> completely discontinuing those services.
>
> I'm wondering if others here have gone through that process and have any
> advice as to how to go about it.
>
> --
>
> Steve Saner | Senior Network Engineer
>
> ideatek INTERNET FREEDOM FOR ALL
>
> Cell: 620-860-9433 | 111 Old Mill Lane, Buhler, KS 67522 | ideatek.com
> <http://www.ideatek.com/>
>
> This email transmission and any documents, files or previous email
> messages attached to it may contain confidential information. If the reader
> of this message is not the intended recipient or the employee or agent
> responsible for delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you are not or believe you may not
> be the intended recipient, please advise the sender immediately by return
> email or by calling 620.543.5026. Then, please take all steps necessary to
> permanently delete the email and all attachments from your computer system.
> No trees were affected by this transmission – though a few billion photons
> were mildly inconvenienced.
>

Re: Google uploading your plain text passwords

[K. Scott Helms]

Bill,

It's not a theory and it doesn't have to be Chrome to work.  Javascript
does the work to decrypt the data and it's not browser specific.

Read the PDF I supplied that details_excatly_ how the key exchange and
encryption works.

Scott Helms



On Sat, Jun 12, 2021 at 10:35 PM William Herrin  wrote:

> On Sat, Jun 12, 2021 at 3:55 PM K. Scott Helms 
> wrote:
> > I don't think you're lying, but you are mistaken.
> >
> > "I'm not lying. Google's server at passwords.google.com
> > composed an html web page containing my plaintext passwords and sent
> > it to me. Not decrypted by my browser after combining it with a
> > locally stored key. "
> >
> > So, you're not describing all of the possible ways to decrypt data.
> What's happening is that the keys to decrypt the passwords are handed to
> your client (with some checks like a local admin password or pin) when you
> attempt to decrypt a given password.  The passwords _are_ decrypted on your
> device and you did not get a HTML page with your passwords.  Please, go
> look at the source yourself.  What you got was a page that's almost
> entirely javascript and that includes the functions that handle the
> decryption.
> >
> > Don't take my word for it, "When you log in to a website while signed in
> to Chrome, Chrome encrypts your username and password with a secret key
> known only to your device. Then it sends an obscured copy of your data to
> Google. Because the encryption happens before Google’s servers get the
> information, nobody, including Google, learns your username or password."
>
> There's a problem with your theory. The browser I viewed the passwords
> from Google in wasn't Chrome. And it didn't have a local copy of any
> Google passwords or keys. The only place they could have come from was
> Google's server.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Google uploading your plain text passwords

[K. Scott Helms]

Bill,

I don't think you're lying, but you are mistaken.

"I'm not lying. Google's server at passwords.google.com
composed an html web page containing my plaintext passwords and sent
it to me. Not decrypted by my browser after combining it with a
locally stored key. "

So, you're not describing all of the possible ways to decrypt data.  What's
happening is that the keys to decrypt the passwords are handed to your
client (with some checks like a local admin password or pin) when you
attempt to decrypt a given password.  The passwords _are_ decrypted on your
device and you did not get a HTML page with your passwords.  Please, go
look at the source yourself.  What you got was a page that's almost
entirely javascript and that includes the functions that handle the
decryption.

Don't take my word for it, "When you log in to a website while signed in to
Chrome, Chrome encrypts your username and password with a secret key known
only to your device. Then it sends an obscured copy of your data to Google.
Because the encryption happens before Google’s servers get the information,
nobody, including Google, learns your username or password."

https://support.google.com/chrome/answer/10311524?hl=en#zippy=%2Chow-password-protection-works%2Chow-we-protect-your-data

If you want the technical details, please take a look at this paper.  It
goes into detail about the process for Chrome, Firefox, and LastPass.

https://courses.csail.mit.edu/6.857/2020/projects/6-Vadari-Maccow-Lin-Baral.pdf

Scott Helms



On Sat, Jun 12, 2021 at 5:51 PM William Herrin  wrote:

> On Sat, Jun 12, 2021 at 12:10 PM K. Scott Helms 
> wrote:
> >   Scott, Google's computer is able to compose an html document which
> > contains my passwords in plain text. Whatever dance they do to either
> > side of that point in their process, at that point they possess my
> > passwords in plain text. Why is this concept a mystery to anyone?
> >
> > Because it's wrong, they don't have your passwords you do (more
> accurately your device does).  They don't combine the decryption keys with
> the encrypted data, your device does.
>
> Look buddy, I'm not lying. Google's server at passwords.google.com
> composed an html web page containing my plaintext passwords and sent
> it to me. Not decrypted by my browser after combining it with a
> locally stored key. Decrypted on and by Google's server. It's not
> wrong. It's not false. It happened just like that.
>
>
> > You did authorize, you just didn't read the fine print.
>
> I always read the fine print. I'm that guy. I don't always go
> searching the menus for bad defaults but I always read everything they
> bother to tell me I'm agreeing to.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Google uploading your plain text passwords

[K. Scott Helms]

  Scott, Google's computer is able to compose an html document which
contains my passwords in plain text. Whatever dance they do to either
side of that point in their process, at that point they possess my
passwords in plain text. Why is this concept a mystery to anyone?

Because it's wrong, they don't have your passwords you do (more accurately
your device does).  They don't combine the decryption keys with the
encrypted data, your device does. This is the case whenever something is
encrypted rather than hashed.  It's literally impossible to provide a
password saving mechanism that hashes the credentials.


  If I had authorized it, it would indeed be just like any other
password managing web site. I did not knowingly authorize it. They
snuck it on me.

You did authorize, you just didn't read the fine print.  Having said that,
this part of your complaint is definitely the one that has the most merit
IMO since if you enable it on mobile it directs you to a web page that you
can't see at that time.

If you're concerned then I'd recommend setting a synch phrase, which makes
it impossible for Google to decrypt the credentials without you inputting
it and they do not store it.

https://support.google.com/chrome/answer/165139?visit_id=637591216572649483-884903087=1

Scott Helms



On Sat, Jun 12, 2021 at 10:29 AM William Herrin  wrote:

> On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms 
> wrote:
> > Encryption != plain text, just because it's not a hash doesn't mean it's
> problematic (if done correctly).
>
> Scott, Google's computer is able to compose an html document which
> contains my passwords in plain text. Whatever dance they do to either
> side of that point in their process, at that point they possess my
> passwords in plain text. Why is this concept a mystery to anyone?
>
>
> > This is the exact same method that every single password management
> system uses and all are far better for the average user than trying to
> reuse a single password or write them down.
>
> If I had authorized it, it would indeed be just like any other
> password managing web site. I did not knowingly authorize it. They
> snuck it on me.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Google uploading your plain text passwords

[K. Scott Helms]

Encryption != plain text, just because it's not a hash doesn't mean it's
problematic (if done correctly).  This is the exact same method that every
single password management system uses and all are far better for the
average user than trying to reuse a single password or write them down.

Scott Helms



On Fri, Jun 11, 2021 at 12:53 PM William Herrin  wrote:

> On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho
>  wrote:
> > Google does not have access to your plain-text passwords in either case.
>
> If they can display the plain text passwords to me on my screen in a
> non-Google web browser then they have access to my plain text
> passwords. Everything else is semantics.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Parler

[K. Scott Helms]

They certainly have been many many times, but that's an entirely
different animal than the rules for content hosting and publishing.
Actions from network providers have (AFAIK) always been in conjunction
with some traffic from or to the violating party rather than an
otherwise legal content hosting arrangement.


Scott Helms


On Sun, Jan 10, 2021 at 9:05 PM mark seery  wrote:
>
> I assume multiple networks/ ISPs that have acceptable use policies that call 
> out criminality and incitement to violence, for example:
>
> https://www.xfinity.com/support/articles/comcast-acceptable-use-policy
>
> Have these AUPs been invoked previously for these reasons, or would that be 
> new territory?
>
> Sent from Mobile Device
>
> On Jan 10, 2021, at 2:52 PM, K. Scott Helms  wrote:
>
> 
> Right, it's not a list for content hosting.
>
> Scott Helms
>
> On Sun, Jan 10, 2021, 5:42 PM  wrote:
>>
>> No, this is a list for Network Operators.
>>
>> Sent from my iPhone
>>
>> On Jan 10, 2021, at 5:32 PM, K. Scott Helms  wrote:
>>
>> 
>> This is a list for pushing bits.  The fact that many/most of us have other 
>> businesses doesn't make this an appropriate forum for SIP issues (to use my 
>> own work as an example).
>>
>> On Sun, Jan 10, 2021, 4:52 PM  wrote:
>>>
>>> This is a list for Network Operators, AWS certainly operates networks.
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 10, 2021, at 4:27 PM, K. Scott Helms  wrote:
>>>
>>> 
>>> No,
>>>
>>> It really does not.  Section 230 only applies to publishers, and not to 
>>> network providers.  If this were a cloud hosting provider list then you'd 
>>> be correct, but as a network provider's list it does not belong here.
>>>
>>>
>>> Scott Helms
>>>
>>>
>>>
>>> On Sun, Jan 10, 2021 at 3:21 PM Lady Benjamin PD Cannon  
>>> wrote:
>>>>
>>>> As network operations and compute/cloud/hosting operations continue to 
>>>> coalesce, I very much disagree with you.  Section 230 is absolutely 
>>>> relevant, this discussion is timely and relevant, and it directly affects 
>>>> me as both a telecom and cloud compute/services provider.
>>>>
>>>>
>>>> —L.B.
>>>>
>>>> Lady Benjamin PD Cannon, ASCE
>>>> 6x7 Networks & 6x7 Telecom, LLC
>>>> CEO
>>>> b...@6by7.net
>>>> "The only fully end-to-end encrypted global telecommunications company in 
>>>> the world.”
>>>> FCC License KJ6FJJ
>>>>
>>>> 
>>>> 
>>>>
>>>> On Jan 10, 2021, at 12:13 PM, K. Scott Helms  
>>>> wrote:
>>>>
>>>> It's not, and frankly it's disappointing to see people pushing an agenda 
>>>> here.
>>>>
>>>>
>>>> Scott Helms
>>>>
>>>>
>>>> On Sun, Jan 10, 2021 at 9:37 AM  wrote:
>>>>
>>>>
>>>> NANOG is a group of Operators, discussion does not have to be about 
>>>> networking. I have already explained how this represents a significant 
>>>> issue for Network Operators.
>>>>
>>>> On Jan 10, 2021, at 9:09 AM, Mike Bolitho  wrote:
>>>>
>>>> 
>>>> It has nothing to do with networking. Their decision was necessarily 
>>>> political. If you can specifically bring up an issue, beyond speculative, 
>>>> on how their new chosen CDN is somehow now causing congestion or routing 
>>>> issues on the public internet, then great. But as of now, that isn't even 
>>>> a thing. It's just best to leave it alone because it will devolve into 
>>>> chaos.
>>>>
>>>> - Mike Bolitho
>>>>
>>>> On Sun, Jan 10, 2021, 6:54 AM  wrote:
>>>>
>>>>
>>>> Why? This is extremely relevant to network operators and is not political 
>>>> at all.
>>>>
>>>> On Jan 10, 2021, at 8:51 AM, Mike Bolitho  wrote:
>>>>
>>>> 
>>>> Can we please not go down this rabbit hole on here? List admins?
>>>>
>>>> - Mike Bolitho
>>>>
>>>> On Sun, Jan 10, 2021, 1:26 AM William Herrin  wrote:
>>>>
>>>>
>>>> Anybody looking for a new customer opportunity? It seems Parler is in
>>>> search of a new service provider. Vendors need only provide all the
>>>> proprietary AWS APIs that Parler depends upon to function.
>>>>
>>>> https://www.washingtonpost.com/technology/2021/01/09/amazon-parler-suspension/
>>>>
>>>> Regards,
>>>> Bill HErrin
>>>>
>>>>

Re: Parler

[K. Scott Helms]

Right, it's not a list for content hosting.

Scott Helms

On Sun, Jan 10, 2021, 5:42 PM  wrote:

> No, this is a list for Network Operators.
>
> Sent from my iPhone
>
> On Jan 10, 2021, at 5:32 PM, K. Scott Helms 
> wrote:
>
> 
> This is a list for pushing bits.  The fact that many/most of us have other
> businesses doesn't make this an appropriate forum for SIP issues (to use my
> own work as an example).
>
> On Sun, Jan 10, 2021, 4:52 PM  wrote:
>
>> This is a list for Network Operators, AWS certainly operates networks.
>>
>> Sent from my iPhone
>>
>> On Jan 10, 2021, at 4:27 PM, K. Scott Helms 
>> wrote:
>>
>> 
>> No,
>>
>> It really does not.  Section 230 only applies to publishers, and not to
>> network providers.  If this were a cloud hosting provider list then you'd
>> be correct, but as a network provider's list it does not belong here.
>>
>>
>> Scott Helms
>>
>>
>>
>> On Sun, Jan 10, 2021 at 3:21 PM Lady Benjamin PD Cannon 
>> wrote:
>>
>>> As network operations and compute/cloud/hosting operations continue to
>>> coalesce, I very much disagree with you.  Section 230 is absolutely
>>> relevant, this discussion is timely and relevant, and it directly affects
>>> me as both a telecom and cloud compute/services provider.
>>>
>>>
>>> —L.B.
>>>
>>> Lady Benjamin PD Cannon, ASCE
>>> 6x7 Networks & 6x7 Telecom, LLC
>>> CEO
>>> b...@6by7.net
>>> "The only fully end-to-end encrypted global telecommunications company
>>> in the world.”
>>> FCC License KJ6FJJ
>>>
>>> 
>>> 
>>>
>>> On Jan 10, 2021, at 12:13 PM, K. Scott Helms 
>>> wrote:
>>>
>>> It's not, and frankly it's disappointing to see people pushing an agenda
>>> here.
>>>
>>>
>>> Scott Helms
>>>
>>>
>>> On Sun, Jan 10, 2021 at 9:37 AM  wrote:
>>>
>>>
>>> NANOG is a group of Operators, discussion does not have to be about
>>> networking. I have already explained how this represents a significant
>>> issue for Network Operators.
>>>
>>> On Jan 10, 2021, at 9:09 AM, Mike Bolitho  wrote:
>>>
>>> 
>>> It has nothing to do with networking. Their decision was necessarily
>>> political. If you can specifically bring up an issue, beyond speculative,
>>> on how their new chosen CDN is somehow now causing congestion or routing
>>> issues on the public internet, then great. But as of now, that isn't even a
>>> thing. It's just best to leave it alone because it will devolve into chaos.
>>>
>>> - Mike Bolitho
>>>
>>> On Sun, Jan 10, 2021, 6:54 AM  wrote:
>>>
>>>
>>> Why? This is extremely relevant to network operators and is not
>>> political at all.
>>>
>>> On Jan 10, 2021, at 8:51 AM, Mike Bolitho  wrote:
>>>
>>> 
>>> Can we please not go down this rabbit hole on here? List admins?
>>>
>>> - Mike Bolitho
>>>
>>> On Sun, Jan 10, 2021, 1:26 AM William Herrin  wrote:
>>>
>>>
>>> Anybody looking for a new customer opportunity? It seems Parler is in
>>> search of a new service provider. Vendors need only provide all the
>>> proprietary AWS APIs that Parler depends upon to function.
>>>
>>>
>>> https://www.washingtonpost.com/technology/2021/01/09/amazon-parler-suspension/
>>>
>>> Regards,
>>> Bill HErrin
>>>
>>>
>>>

Re: Parler

[K. Scott Helms]

This is a list for pushing bits.  The fact that many/most of us have other
businesses doesn't make this an appropriate forum for SIP issues (to use my
own work as an example).

On Sun, Jan 10, 2021, 4:52 PM  wrote:

> This is a list for Network Operators, AWS certainly operates networks.
>
> Sent from my iPhone
>
> On Jan 10, 2021, at 4:27 PM, K. Scott Helms 
> wrote:
>
> 
> No,
>
> It really does not.  Section 230 only applies to publishers, and not to
> network providers.  If this were a cloud hosting provider list then you'd
> be correct, but as a network provider's list it does not belong here.
>
>
> Scott Helms
>
>
>
> On Sun, Jan 10, 2021 at 3:21 PM Lady Benjamin PD Cannon 
> wrote:
>
>> As network operations and compute/cloud/hosting operations continue to
>> coalesce, I very much disagree with you.  Section 230 is absolutely
>> relevant, this discussion is timely and relevant, and it directly affects
>> me as both a telecom and cloud compute/services provider.
>>
>>
>> —L.B.
>>
>> Lady Benjamin PD Cannon, ASCE
>> 6x7 Networks & 6x7 Telecom, LLC
>> CEO
>> b...@6by7.net
>> "The only fully end-to-end encrypted global telecommunications company in
>> the world.”
>> FCC License KJ6FJJ
>>
>> 
>> 
>>
>> On Jan 10, 2021, at 12:13 PM, K. Scott Helms 
>> wrote:
>>
>> It's not, and frankly it's disappointing to see people pushing an agenda
>> here.
>>
>>
>> Scott Helms
>>
>>
>> On Sun, Jan 10, 2021 at 9:37 AM  wrote:
>>
>>
>> NANOG is a group of Operators, discussion does not have to be about
>> networking. I have already explained how this represents a significant
>> issue for Network Operators.
>>
>> On Jan 10, 2021, at 9:09 AM, Mike Bolitho  wrote:
>>
>> 
>> It has nothing to do with networking. Their decision was necessarily
>> political. If you can specifically bring up an issue, beyond speculative,
>> on how their new chosen CDN is somehow now causing congestion or routing
>> issues on the public internet, then great. But as of now, that isn't even a
>> thing. It's just best to leave it alone because it will devolve into chaos.
>>
>> - Mike Bolitho
>>
>> On Sun, Jan 10, 2021, 6:54 AM  wrote:
>>
>>
>> Why? This is extremely relevant to network operators and is not political
>> at all.
>>
>> On Jan 10, 2021, at 8:51 AM, Mike Bolitho  wrote:
>>
>> 
>> Can we please not go down this rabbit hole on here? List admins?
>>
>> - Mike Bolitho
>>
>> On Sun, Jan 10, 2021, 1:26 AM William Herrin  wrote:
>>
>>
>> Anybody looking for a new customer opportunity? It seems Parler is in
>> search of a new service provider. Vendors need only provide all the
>> proprietary AWS APIs that Parler depends upon to function.
>>
>>
>> https://www.washingtonpost.com/technology/2021/01/09/amazon-parler-suspension/
>>
>> Regards,
>> Bill HErrin
>>
>>
>>

Re: Parler

[K. Scott Helms]

It's not, and frankly it's disappointing to see people pushing an agenda here.


Scott Helms


On Sun, Jan 10, 2021 at 9:37 AM  wrote:
>
> NANOG is a group of Operators, discussion does not have to be about 
> networking. I have already explained how this represents a significant issue 
> for Network Operators.
>
> On Jan 10, 2021, at 9:09 AM, Mike Bolitho  wrote:
>
> 
> It has nothing to do with networking. Their decision was necessarily 
> political. If you can specifically bring up an issue, beyond speculative, on 
> how their new chosen CDN is somehow now causing congestion or routing issues 
> on the public internet, then great. But as of now, that isn't even a thing. 
> It's just best to leave it alone because it will devolve into chaos.
>
> - Mike Bolitho
>
> On Sun, Jan 10, 2021, 6:54 AM  wrote:
>>
>> Why? This is extremely relevant to network operators and is not political at 
>> all.
>>
>> On Jan 10, 2021, at 8:51 AM, Mike Bolitho  wrote:
>>
>> 
>> Can we please not go down this rabbit hole on here? List admins?
>>
>> - Mike Bolitho
>>
>> On Sun, Jan 10, 2021, 1:26 AM William Herrin  wrote:
>>>
>>> Anybody looking for a new customer opportunity? It seems Parler is in
>>> search of a new service provider. Vendors need only provide all the
>>> proprietary AWS APIs that Parler depends upon to function.
>>>
>>> https://www.washingtonpost.com/technology/2021/01/09/amazon-parler-suspension/
>>>
>>> Regards,
>>> Bill HErrin

Re: Centurylink having a bad morning?

[K. Scott Helms]

We've been on hold for more than an hour trying to get an update.

We see the same behavior where they continue to announce our blocks
despite all the interfaces to them being hard down.

Scott Helms


On Sun, Aug 30, 2020 at 8:58 AM Jason Kuehl  wrote:
>
> Well, When I tried calling I got a fast busy, so that's nice.
>
> On Sun, Aug 30, 2020 at 8:33 AM David Hubbard  
> wrote:
>>
>> Same.  Also, as reported on outages list, what’s even worse is that they 
>> appear to be continuing to propagate advertisements from circuits whose 
>> sessions have been turned down.  I validated ours still were via a couple 
>> looking glass portals.  Down Detector shows nearly every major service 
>> provider impacted.
>>
>>
>>
>> They’re not reachable so who knows if they’re even working on it.  I feel 
>> like they’ve been cutting heavily on the network ops side in recent years…
>>
>>
>>
>> From: NANOG  on 
>> behalf of Drew Weaver via NANOG 
>> Reply-To: Drew Weaver 
>> Date: Sunday, August 30, 2020 at 8:23 AM
>> To: "nanog@nanog.org" 
>> Subject: Centurylink having a bad morning?
>>
>>
>>
>> Hello,
>>
>>
>>
>> Woke up this morning to a bunch of reports of issues with connectivity had 
>> to shut down some Level3/CTL connections to get it to return to normal.
>>
>>
>>
>> As of right now their support portal won’t load: 
>> https://www.centurylink.com/business/login/
>>
>>
>>
>> Just wondering what others are seeing.
>>
>>
>
>
>
> --
> Sincerely,
>
> Jason W Kuehl
> Cell 920-419-8983
> jason.w.ku...@gmail.com

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

[K. Scott Helms]

Nick,

Data on blocking inbound TCP or the kinds of gear that mistakenly
labels UDP fragments as DST port 0?

Scott Helms


On Wed, Aug 26, 2020 at 9:00 AM Nick Hilliard  wrote:
>
> K. Scott Helms wrote on 26/08/2020 13:55:
> > To be clear, UDP port 0 is not and probably shouldn't be blocked
> > because some network gear and reporting tools may mistake a fragmented
> > UDP PDU for port 0.  That's an implementation error, but one that may
> > be common enough to create issues for users.
> do you have data on this?
>
> Nick
>

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

[K. Scott Helms]

To be clear, UDP port 0 is not and probably shouldn't be blocked
because some network gear and reporting tools may mistake a fragmented
UDP PDU for port 0.  That's an implementation error, but one that may
be common enough to create issues for users.  Blocking inbound TCP
port 0 is something that I've personally done in dozens of ISP
networks over more than a decade without a single reported issue.

Scott Helms


On Tue, Aug 25, 2020 at 7:39 PM narhiro  wrote:
>
>
> > "Port 0 is a reserved port, which means it should not be used by
> > applications. Network abuse has prompted the need to block this port."
> >
> > "What about UDP IP fragmentation?"
> >
> > I'm not sure I follow this.  The IP packet will be fragmented with UDP
> > inside it.  When the IP packet gets put together the UDP PDU will have
> > a port number.  It's possible that some packet analyzers or network
> > gear will improperly "see" a partial UDP flow as port 0 but that's a
> > mischaracterization of the flow.
> >
> >
> > Scott Helms
> >
> > Scott Helms
> >
> >
> >
> >>> On Tue, Aug 25, 2020 at 8:17 AM Job Snijders  wrote:
> >>>
> >>>> On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote:
> >>> I think a fairly easy thing to do is see what other large retail ISPs
> >>> have done.  Comcast, as an example, lists all of the ports they block
> >>> and 0 is blocked.  I do recommend that port 0 be blocked by all of the
> >>> ISPs I work with and frankly Comcast's list is a pretty good one to
> >>> use in general, though you will get some pushback on things like SMTP.
> >>> https://www.xfinity.com/support/articles/list-of-blocked-ports
> >>
> >> I may be reading the table incorrectly, but it seems to me Comcast is
> >> *not* blocking UDP port 0 according to the above URL?
> >>
> >>> Transit providers are a little bit different, but then again port 0 is
> >>> also different since AFAIK it's never had a legitimate use case.  It's
> >>> always been a reserved port.  I'd personally block it if I ran a
> >>> transit, but I'd be more willing to open it up for one of my large
> >>> customers (in a limited way) than I would on the retail side.
> >>> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
> >>
> >> What about UDP IP fragmentation?
> >>
> >> Kind regards,
> >>
> >> Job

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

[K. Scott Helms]

That's correct, I can only blame my lack of coffee at that point for
the oversight.  I went back and looked at where we have this
implemented and it's only TCP.


Scott Helms


On Tue, Aug 25, 2020 at 8:46 AM Job Snijders  wrote:
>
> On Tue, Aug 25, 2020 at 08:27:24AM -0400, K. Scott Helms wrote:
> > Comcast is blocking it.  From the table on that page.
> >
> > "Port 0 is a reserved port, which means it should not be used by
> > applications. Network abuse has prompted the need to block this port."
>
> The 'Transport' column seems to indicate that TCP port 0 is blocked, but
> not that UDP port 0 is blocked. I believe there are comcast people on
> this mailing list, it would be interesting to hear what the
> considerations were to block one but not the other.
>
> > "What about UDP IP fragmentation?"
> >
> > I'm not sure I follow this.  The IP packet will be fragmented with UDP
> > inside it.  When the IP packet gets put together the UDP PDU will have
> > a port number.  It's possible that some packet analyzers or network
> > gear will improperly "see" a partial UDP flow as port 0 but that's a
> > mischaracterization of the flow.
>
> You are absolutely right. There is no layer-4 header in a fragment.
> 'port 0' in netflow/ipfix traffic analyzer tools when displayed may be
> the result of a lack of ability to label it differently in the
> datastructures used. "mischaracterization" is a fitting word :-)
>
> Kind regards,
>
> Job

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

[K. Scott Helms]

Job,

Comcast is blocking it.  From the table on that page.

"Port 0 is a reserved port, which means it should not be used by
applications. Network abuse has prompted the need to block this port."

"What about UDP IP fragmentation?"

I'm not sure I follow this.  The IP packet will be fragmented with UDP
inside it.  When the IP packet gets put together the UDP PDU will have
a port number.  It's possible that some packet analyzers or network
gear will improperly "see" a partial UDP flow as port 0 but that's a
mischaracterization of the flow.


Scott Helms

Scott Helms



On Tue, Aug 25, 2020 at 8:17 AM Job Snijders  wrote:
>
> On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote:
> > I think a fairly easy thing to do is see what other large retail ISPs
> > have done.  Comcast, as an example, lists all of the ports they block
> > and 0 is blocked.  I do recommend that port 0 be blocked by all of the
> > ISPs I work with and frankly Comcast's list is a pretty good one to
> > use in general, though you will get some pushback on things like SMTP.
> >
> > https://www.xfinity.com/support/articles/list-of-blocked-ports
>
> I may be reading the table incorrectly, but it seems to me Comcast is
> *not* blocking UDP port 0 according to the above URL?
>
> > Transit providers are a little bit different, but then again port 0 is
> > also different since AFAIK it's never had a legitimate use case.  It's
> > always been a reserved port.  I'd personally block it if I ran a
> > transit, but I'd be more willing to open it up for one of my large
> > customers (in a limited way) than I would on the retail side.
> >
> > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
>
> What about UDP IP fragmentation?
>
> Kind regards,
>
> Job

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

[K. Scott Helms]

Douglas,

I think a fairly easy thing to do is see what other large retail ISPs have
done.  Comcast, as an example, lists all of the ports they block and 0 is
blocked.  I do recommend that port 0 be blocked by all of the ISPs I work
with and frankly Comcast's list is a pretty good one to use in general,
though you will get some pushback on things like SMTP.

https://www.xfinity.com/support/articles/list-of-blocked-ports

Transit providers are a little bit different, but then again port 0 is also
different since AFAIK it's never had a legitimate use case.  It's always
been a reserved port.  I'd personally block it if I ran a transit, but I'd
be more willing to open it up for one of my large customers (in a limited
way) than I would on the retail side.

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml


Scott Helms



On Tue, Aug 25, 2020 at 7:16 AM Douglas Fischer 
wrote:

> I think that the subject of the e-mail is very self-explanatory.
>
> With some analysis of what is running over our network, ISP or ITP, we
> will be able to see some TCP/UDP(mostly UDP) packets with source or
> destination to port 0.
>
> I can think of a genuine use of it.
> (Maybe someone cloud help me see what I'm not seen.)
>
> So I have two questions:
>
> a) Should an ISP block that Kind of traffic?
> (like anti-spoofing on BNG/B-RAS)
>
> b) Should a Transit Provider block that Kind of traffic?
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

Re: How to manage Static IPs to customers

[K. Scott Helms]

The spec allows for bridging or layer 3 but none of the major or certified
manufacturers support bridging on larger platforms.  (>1000 modems)

Scott Helms



On Fri, May 8, 2020 at 3:56 PM Brandon Martin 
wrote:

> I'm curious...
>
> Is it part of the DOCSIS spec that the CMTS terminates L3, or can they
> bridge to IEEE 802(.3) and delegate that to some other piece of gear?
> I'm unfortunately not familiar with the MSO world much at all aside from
> a little bit of L1.
>
> --
> Brandon Martin
>

Re: How to manage Static IPs to customers

[K. Scott Helms]

Javier,

There's really no good way to handle this without routing or tunneling that
I've been able to find in a very long time.  (SD-WAN can help, but it's
just a fancy way to tunnel in this regard.)  It's pretty amazing that this
is such an issue, but it remains so.  I have tried to work around this
using BSoD (
https://specification-search.cablelabs.com/business-services-over-docsis-layer-2-virtual-private-networks
)
but we eventually abandoned the effort because it rapidly became to
expensive to scale to solve a niche problem.

Scott Helms



On Fri, May 8, 2020 at 8:58 AM Javier Gutierrez Guerra <
guer...@westmancom.com> wrote:

> That's surprising to me, I have no intentions to do routing with our cable
> subscribers, that seems like a headache for both sides
> Today we have specific ranges within subnets from where we assign IPs to
> customers, my main problem that I'm trying to get around is having to
> change a customer static IP if their node gets splitter and I have to mode
> them to a different CMTS
>
> Thanks,
>
> Javier Gutierrez Guerra
>
>
>
> -Original Message-
> From: NANOG  On Behalf Of Bryan Fields
> Sent: Thursday, May 7, 2020 5:57 PM
> To: nanog@nanog.org
> Subject: Re: How to manage Static IPs to customers
>
> CAUTION: This email is from an external source. Do not click links or open
> attachments unless you recognize the sender and know the content is safe.
>
> On 5/7/20 5:54 PM, Brandon Jackson via NANOG wrote:
> > I have seen (Charter) and heard quite a few run RIP or some other
> > routing protocol on the CPE.
>
> Yep, it's RIP.  They don't support IPv6 on this either.  I've been asking
> for
> IPv6 since 2006, it's always next year.
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Re: Backup over 4G/LTE

[K. Scott Helms]

There are lots of options to solve that problem.

Peplink, 128T, Viptela (Cisco), Velocloud (VMWare), etc.

Scott Helms



On Tue, Jan 28, 2020 at 6:31 PM K MEKKAOUI  wrote:

> Dear NANOG Community,
>
>
>
> Can anyone help with any device information that provides redundancy for
> business internet access? In other words when the internet provided through
> the cable modem fails the 4G/LTE takes over automatically to provide
> internet access to the client.
>
>
>
> Thank you
>
>
>
> KARIM M.
>
>
>

Re: This DNS over HTTP thing

[K. Scott Helms]

They almost have to change the default since there are (comparatively) very
few DoH providers compared to DNS providers.

On Tue, Oct 1, 2019, 2:40 PM Damian Menscher via NANOG 
wrote:

> On Tue, Oct 1, 2019 at 12:24 PM Jay R. Ashworth  wrote:
>
>> - Original Message -
>> > From: "Stephane Bortzmeyer" 
>> > To: "Jeroen Massar" 
>>
>> >> While the 'connection to the recursor' is 'encrypted', the recursor
>> >> is still in clear text... one just moves who can see what you are
>> >> doing with this.
>> >
>> > As with any cryptographic protocol. Same thing with VPNs, SSH and
>> > whatever: the remote end can see what you do. What's your point?
>>
>> I'm still assimilating this, but based on what I've read this half hour,
>> his point is that "*it's none of Alphabet's damn business* where I go that
>> isn't Google".
>>
>
> What's missing from this discussion are some basic facts, like "is Google
> going to change your DNS settings to 8.8.8.8?"
>
> The opening paragraph of
> https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html
>  reads:
>
> "This experiment will be done in collaboration with DNS providers who
> already support DoH, with the goal of improving our mutual users’ security
> and privacy by upgrading them to the DoH version of their current DNS
> service. With our approach, the DNS service used will not change, only the
> protocol will. As a result, existing content controls of your current DNS
> provider, including any existing protections for children, will remain
> active."
>
> Could someone provide a reference of Google saying they'll change the
> default nameserver?  Without that, I think all of Jeroen's arguments fall
> apart?
>
> Damian
>

Re: Packetstream - how does this not violate just about every provider's ToS?

[K. Scott Helms]

After all, it worked for Napster


Scott Helms



On Thu, Apr 25, 2019 at 3:23 PM John Levine  wrote:

> In article  you write:
> >-=-=-=-=-=-
> >
> >feeling cranky, are we, job?   (accusing an antispam expert of spamming
> on a mailing list by having too long a .sig?)
> >but it’s true!  anne runs the internet, and the rest of us (except for
> ICANN GAC representatives) all accept that.
> >
> >to actually try to make a more substantial point, i am quite curious how
> the AUPs of carriers try to disallow
> >bandwidth resale while permitting
> >
> >• cybercafe operations and other “free wifi" (where internet service
> might be provided for patrons in a
> >hotel or cafe)
> >• wireless access point schemes where you make money or get credit for
> allowing use of your bandwidth (e.g. Fon)
> >• other proxy services that use bandwidth such as tor exit nodes and
> openvpn gateways
>
> To belabor the fairly obvious, residential and business service are
> different even if the technology is the same.  For example, Comcast's
> residential TOS says:
>
>   You agree that the Service(s) and the Xfinity Equipment will be used
>   only for personal, residential, non-commercial purposes, unless
>   otherwise specifically authorized by us in writing. You are prohibited
>   from reselling or permitting another to resell the Service(s) in whole
>   or in part, ... [ long list of other forbidden things ]
>
> Their business TOS is different.  It says no third party use unless
> your agreement permits it, so I presume they have a coffee shop plan.
> (The agreements don't seem to be on their web site.)  I'd also observe
> that coffee shop wifi isn't "resale" since it's free, it's an amenity.
>
> As to how do these guys think they'll get away with it, my guess is
> that they heard that "disruption" means ignoring laws and contracts
> and someone told them that is a good thing.
>
> R's,
> John
>

Re: Comcast storing WiFi passwords in cleartext?

[K. Scott Helms]

Tom,

No, and I would hope that they were storing it in an encrypted format and
then decrypting it on the fly for display in the customer portal.

Scott Helms



On Thu, Apr 25, 2019 at 1:55 PM Tom Beecher  wrote:

> As much as it pains me to Devil's Advocate for Comcast... Has anyone
> proven that they are storing this PSK in cleartext? From the original
> StackExchange post :
>
> " When I went to the account web page, it showed me my password. I
> changed the password and it instantly showed the new password on the
> account web page (after refresh). "
>
> The SNMP response is essentially cleartext , sure. But perhaps they are
> performing the query from a modem management network only accessible from
> the RF side, the transmission back to the CS backend is encrypted in
> flight, and the data is also encrypted at rest until retrieved and
> decrypted by a agent or the end user via the web portal. Nothing has been
> shown that I can recall reading that proves or disproves any of that.
>
>
>
> On Thu, Apr 25, 2019 at 1:17 PM Doug Barton  wrote:
>
>> On 4/25/19 8:04 AM, K. Scott Helms wrote:
>> > Just so you know, if you have an embedded router from a service
>> provider
>> > all of that data is _already_ being transmitted and has been for a long
>> > long time.
>>
>> Responding to a pseudo-random message ...
>>
>> If you are an average consumer and purchase a managed solution (in this
>> case a WAP that comes as part of your package) I think it's perfectly
>> reasonable for the vendor to manage it accordingly, even if said
>> consumer doesn't fully understand the implications of that decision.
>>
>> In my mind, the problem here is not that the vendor has access to this
>> data, it's that they are STORING it in the first place, and storing it
>> in the clear to boot. In the hypothetical service call that we've
>> speculated is the driver for this, the extra 15 or 20 seconds that it
>> would take to pull the data via SNMP is in the noise.
>>
>> There are two mindsets that desperately need changing in the tech world:
>>
>> 1. Do not store data that you don't have a legitimate requirement to store
>> 2. Do not store anything even remotely sensitive in the clear
>>
>> We live in a world of all breaches, all of the time. So we need to start
>> thinking not in terms of just protecting said data from the outside, but
>> rather in terms of limiting the attack surface to start with, and
>> protecting the data at rest. So that WHEN there is a breach, whether
>> from within or without, the damage will be minimal.
>>
>> As many have pointed out, this information is freely available via SNMP,
>> so it's a classic example of something that didn't need to be stored in
>> the first place.
>>
>> Doug
>>
>

Re: Comcast storing WiFi passwords in cleartext?

[K. Scott Helms]

Doug,

I don't disagree, but things are pretty complicated, much more so than they
might seem from the outside.  First, if the configuration isn't stored
there's literally no way to have a backup for most of the CPE vendors so
there's definitely reason to have it duplicated in the service providers'
systems.  Very few allow for end users to download their router
configuration via the admin page and I know of none that encrypt that
configuration before it is delivered to the end user's computer.  (It's
also relevant that the usage for those vendors that do allow end users to
backup the config is vanishingly low.)  If we're looking at a TR-069 based
system for managing the WiFi and router components it's not really feasible
to do a real time grab of that data since that process can take up to ~5
minutes depending on your periodic inform settings in your ACS.  That's
because TR-069 is inherently a push technology (from the CPE to the ACS)
rather than a pull like SNMP.

The next piece is that a DOCSIS configuration file itself, which in some
cases contains these parameters, is by the standard required to be
delivered via insecure protocols, namely TFTP.  Newer devices have options
to allow for TLS secured HTTP, but that's very rare today in production
provisioning systems, and in case the secured protocols are all still
optional in the spec.  In general the config file itself is stored in it's
text format on the provisioning systems or if the file is dynamically
generated the user specific parameters are held in a database with the
general ones coming from a template for that class of service.

Again, I'm not disagreeing with your premise but the service providers
directly control a small piece of the overall process and we're still
working with standards from earlier times.  Most cable operators have
gotten rid of their DOCSIS 2.0 (1.0 and 1.1 as well) but it's not uncommon
to find a handful of users with (mostly customer owned) D2 devices that the
provisioning and OSS systems still have to deal with.  DOCSIS 3.0 devices
are the majority and 3.1 devices are just now being rolled out in large
numbers.

In short, not everything is quickly retrievable, much of the configuration
is in fact generated by the service provider and must be maintained because
the modem needs to download its configuration every time it reboots, and
the vendors and associations in the provisioning and OSS space have more
input than the operators themselves.

Scott Helms



On Thu, Apr 25, 2019 at 1:16 PM Doug Barton  wrote:

> On 4/25/19 8:04 AM, K. Scott Helms wrote:
> > Just so you know, if you have an embedded router from a service provider
> > all of that data is _already_ being transmitted and has been for a long
> > long time.
>
> Responding to a pseudo-random message ...
>
> If you are an average consumer and purchase a managed solution (in this
> case a WAP that comes as part of your package) I think it's perfectly
> reasonable for the vendor to manage it accordingly, even if said
> consumer doesn't fully understand the implications of that decision.
>
> In my mind, the problem here is not that the vendor has access to this
> data, it's that they are STORING it in the first place, and storing it
> in the clear to boot. In the hypothetical service call that we've
> speculated is the driver for this, the extra 15 or 20 seconds that it
> would take to pull the data via SNMP is in the noise.
>
> There are two mindsets that desperately need changing in the tech world:
>
> 1. Do not store data that you don't have a legitimate requirement to store
> 2. Do not store anything even remotely sensitive in the clear
>
> We live in a world of all breaches, all of the time. So we need to start
> thinking not in terms of just protecting said data from the outside, but
> rather in terms of limiting the attack surface to start with, and
> protecting the data at rest. So that WHEN there is a breach, whether
> from within or without, the damage will be minimal.
>
> As many have pointed out, this information is freely available via SNMP,
> so it's a classic example of something that didn't need to be stored in
> the first place.
>
> Doug
>

Re: Comcast storing WiFi passwords in cleartext?

[K. Scott Helms]

Just so you know, if you have an embedded router from a service provider
all of that data is _already_ being transmitted and has been for a long
long time.  If it's being collected via SNMPv2c it is being transmitted in
the clear (though hopefully encrypted via BPI+ between the modem and the
CMTS).  If it's being collected via TR-069 it _may_ (should be) encrypted
in transit but in my experience that isn't guaranteed and when its being
sent over TLS there's often a self signed cert in the chain.

Scott Helms



On Thu, Apr 25, 2019 at 10:45 AM Benjamin Sisco 
wrote:

> On 4/24/ 2019 10:34 AM, Seth Mattinen wrote:
>
> > That's looking at it from a technical perspective when it isn't a
> technical problem. People that buy "includes wifi" from their ISP often
> need extreme amounts of help with it, and thus the wifi credentials are
> stored and transmitted in plain text for tech support reasons.
>
> While I agree that the underlying need is to provide fast and effective
> customer service - it is ultimately a technical problem.  As it's been
> pointed out in subsequent posts WiFi is the leading cause of customer calls
> to an ISP offering the service.  Security and "ease of use" are often at
> odds with each other, and implementing the former with the latter is the
> challenge many of us wake up to each and every day.  The information should
> be encrypted at rest and in transit and could easily be decrypted by the
> CSP platform for use by customer support staff at the time of need when
> cusetomers call in - which would address the concern.
>
> In my experience, bad practice is easily replicated.  What else is
> transmitted in cleartext?  Today it's the WiFi password, tomorrow it's your
> login, port forwarding, DMZ, and other details that are far more useful to
> a remote attacker than your WiFi password.
>
>
>
>
> -Original Message-
> From: NANOG  On Behalf Of Seth Mattinen
> Sent: Wednesday, April 24, 2019 10:34 AM
> To: nanog@nanog.org
> Subject: Re: Comcast storing WiFi passwords in cleartext?
>
> Notice: This message originated outside of Just Associates. Verify the
> source & exercise caution with links and attachments.
>
> On 4/24/19 8:13 AM, Benjamin Sisco wrote:
> > The bigger concern should be the cleartext portion of the subject.
> There’s ZERO reason to store or transmit any credentials (login, service,
> keys, etc.), in any location, in an unencrypted fashion regardless of their
> perceived value or purpose.  Unless you like risk.
>
>
> That's looking at it from a technical perspective when it isn't a
> technical problem. People that buy "includes wifi" from their ISP often
> need extreme amounts of help with it, and thus the wifi credentials are
> stored and transmitted in plain text for tech support reasons.
>
> ~Seth
> Confidentiality Notice: This e-mail communication and any attachments may
> contain confidential and privi­leged information for the use of the
> designated recipients named above. If you are not the intended recipient,
> you are hereby notified that you have received this communication in error
> and that any review, disclosure, dissemination, distribution or copying of
> it or its contents is prohibited. If you have received this communica­tion
> in error, please notify me immediately by replying to this message and
> deleting it from your computer. Thank you.
>

Re: Comcast storing WiFi passwords in cleartext?

[K. Scott Helms]

James,

By the DOCSIS standard and every North American MSO's ToS I've seen (I've
worked with or for about 200 different cable operators over the last 20
years) your cable modem is always managed and the cable operator _always_
has access to its configuration and settings via SNMP.  The configuration
file for a DOCSIS cable modem is nothing more than a list of SNMP OIDs with
their values set the way the operator wants them.  This has been true since
DOCSIS 1.0 (which doesn't make it correct, just common).  Now, DOCSIS is
primarily deployed with SNMP version 2c though more and more operators,
especially the larger ones, are moving or have to SNMPv3.  I mention this
because every cable modem on a given CMTS that's deployed in SNMPv2c mode
will (should for proper functioning) have the same SNMP READ and WRITE
strings.  SNMPv2c traffic is clear text UDP with no standardized methods of
encryption available to the industry.  To mitigate this to an extent part
of the cable modem's configuration will (best practice anyway) have
filtering rules to only accept SNMP traffic from a given IP address or
subnet and traffic between the CMTS and the modem should be encrypted via
BPI+ for some minimal security.  (A minor note, the router interface for a
combo unit by CableLabs OSS standards will not respond to SNMP traffic on
its public address by default and almost all of the SNMP traffic will be to
the modem's RFC1918 address.)  What I'm getting at is that the for DOCSIS
(and FTTH and most DSL flavors as well) the service provider has and has
had access to all the settings for a very long time.  What's changed is
that customers wanted to WiFi to be provided by the operator and
importantly supported by the operator.

" I have yet to hear any discussion of the business value of access to WiFi
network password, especially as compared to billing and identity data.
Also, remote management of local networks by definition requires
credentials stored off site from the customer. To the typical customer,
loss of connectivity is much worse than a small chance of sharing the WiFi."

Let me provide something in this regard.  The most common support call
category, by a large number, is the WiFi category.  In excess of 55% of all
support calls (regardless of how the customer describes them) end up being
WiFi issues.  The most common specific call in that category is some
variation of, "I've forgotten my WiFi password and I need to get my new
iPad online."  As a service provider your choices are to say I can reset
your WiFi PSK, which allows the new device to come online but breaks
everything else that was connected, or to allow the support rep and/or
customer to recover the passphrase.  In short, the ability to recover the
passphrase is strongly preferred by end users over resetting it and frankly
is much less expensive for the operator.

I've helped supply this functionality to a large number of operators and in
general the implementations _should_ at a minimum be able to capture the
agent who recovered the passphrase, the time/date, who the agent was on the
phone with, whether the agent correctly verified the identity of the
caller, and if the agent followed all other procedures laid by the service
provider.

Scott Helms



On Thu, Apr 25, 2019 at 8:38 AM James R Cutler 
wrote:

> On Apr 25, 2019, at 8:26 AM, K. Scott Helms 
> wrote:
>
> People are missing the point here.  This is _not_ a Comcast "issue" this
> same data is available to every single cable operator in the US who deploys
> bundled modem/router/APs that follow the CableLabs standard.  They may or
> may not expose the data to their end customers, but it's stored in their
> systems and is often available to their support teams.
>
> http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt
>
> The same thing applies to most FTTH and xDSL deployments.  They use TR-069
> to collect the data instead of SNMP but the object model is the same.  The
> WiFi MIB above is explicitly built to mimic TR-181 functionality.
>
> Scott Helms
>
>
>
> On Wed, Apr 24, 2019 at 5:48 PM Rich Kulawiec  wrote:
>
>> On Wed, Apr 24, 2019 at 03:13:33PM +, Benjamin Sisco wrote:
>> > The bigger concern should be the cleartext portion of the subject.
>>
>> Yes, and the availability of all this to anyone who hacks Comcast
>> customer support.
>>
>> —rsk
>
>
> I have yet to hear any discussion of the business value of access to WiFi
> network password, especially as compared to billing and identity data.
> Also, remote management of local networks by definition requires
> credentials stored off site from the customer. To the typical customer,
> loss of connectivity is much worse than a small chance of sharing the WiFi.
>
> Narrowing the discussion back to Comcast, credentials for “guest” WiFi
> seem to be more used than purloined SNMP MIB data.
>

Re: Comcast storing WiFi passwords in cleartext?

[K. Scott Helms]

People are missing the point here.  This is _not_ a Comcast "issue" this
same data is available to every single cable operator in the US who deploys
bundled modem/router/APs that follow the CableLabs standard.  They may or
may not expose the data to their end customers, but it's stored in their
systems and is often available to their support teams.

http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt

The same thing applies to most FTTH and xDSL deployments.  They use TR-069
to collect the data instead of SNMP but the object model is the same.  The
WiFi MIB above is explicitly built to mimic TR-181 functionality.

Scott Helms



On Wed, Apr 24, 2019 at 5:48 PM Rich Kulawiec  wrote:

> On Wed, Apr 24, 2019 at 03:13:33PM +, Benjamin Sisco wrote:
> > The bigger concern should be the cleartext portion of the subject.
>
> Yes, and the availability of all this to anyone who hacks Comcast
> customer support.
>
> ---rsk
>

Re: Comcast storing WiFi passwords in cleartext?

[K. Scott Helms]

While it's correct that it's stored in the vendor proprietary MIB this
information is commonly retrieved from the CableLabs standard MIB and via
TR-181 in DSL and FTTH gear.

I wrote up an answer on the security forum originally refereneced, but for
convenience here is the same text.


The PSK passphrase is (by design) stored in a retrievable format by the
Modem vendor, in this case Arris, but the same standard is supported by
many other modem vendors. In DOCSIS cable modems this is most commonly done
via SNMP against this specific OID:

clabWIFIAccessPointSecurityKeyPassphrase OBJECT-TYPE SYNTAX SnmpAdminString
(SIZE(0..63))
MAX-ACCESS read-create STATUS current DESCRIPTION "This object is defined
in TR-181 Device.WiFi.AccessPoint{i}.Security.KeyPassphrase." REFERENCE
"TR-181 Device Data Model for TR-069." ::=
{clabWIFIAccessPointSecurityEntry 5

This is part of the CableLabs WiFi MIB:

http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt

Which is is in turn based on the TR-069 sub-standard of TR-181:

https://cwmp-data-models.broadband-forum.org/tr-181-2-11-0.html#D.Device:2.Device.WiFi.AccessPoint
.{i}.Security.KeyPassphrase

http://www.broadband-forum.org/download/TR-181_Issue-2_Amendment-2.pdf

Not only does this apply to cable modems, but many DSL and FTTH endpoints
will also allow the service provider to retrieve your PSK passphrases and a
litany of other settings.

This allows for end users to have their settings backed up in case of a
device having to be replaced or much more commonly for call centers to be
able to retrieve some of the settings, like the pass phrase, when a
customer calls in because they can't remember it.
Scott Helms



On Tue, Apr 23, 2019 at 11:34 PM Luke Guillory 
wrote:

> Yes it's in the router, accessed via the following MIB.
>
>
>
> Name arrisRouterWPAPreSharedKey
> OID  .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2
> MIB  ARRIS-ROUTER-DEVICE-MIB
> Syntax   OCTET STRING (SIZE (8..64))
> Access   read-write
> Status   current
>
> Descri   Sets the WPA Pre-Shared Key (PSK) used by this service set.  This
>value MUST be either a 64 byte hexadecimal number, OR an 8
> to 63
>character ASCII string.
>
>
> Which returns the following.
>
>
> OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10004
> Value: F2414322EE3D9263
> Type: OctetString
>
> OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10003
> Value: F2414322EE3D9263
> Type: OctetString
>
> OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10002
> Value: F2414322EE3D9263
> Type: OctetString
>
> OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10001
> Value: F2414322EE3D9263
> Type: OctetString
>
>
>
>
>
> Ns
>
>
>
>
>
>
>
> -Original Message-
> From: Peter Beckman [mailto:beck...@angryox.com]
> Sent: Tuesday, April 23, 2019 9:35 PM
> To: Luke Guillory
> Cc: Laurent Dumont; NANOG
> Subject: Re: Comcast storing WiFi passwords in cleartext?
>
> On Tue, 23 Apr 2019, Peter Beckman wrote:
>
> > On Wed, 24 Apr 2019, Luke Guillory wrote:
> >
> >> OP said they logged into their account and went to the security
> >> portion of the portal. So one can assume they're the ISP or I don’t
> >> see the point in asking how Comcast would know the info.
> >
> > It is entirely possible that an account separate and hidden from the
> > customer account would be able to access the administrative controls
> > of the router. It is also plausible that the access does not use a
> > username/password to authenticate but another, hopefully secure method.
> >
> > One could make this access secure by:
> >
> >1. Ensuring any connection originated from Company-controlled IP space
> >2. Username/Password are not provided to the CS agent but is merely a
> >button they press, after properly authenticating themselves as
> well
> >as authenticating the customer, that would pass a one-time use
> >token to access the device
> >3. Every token use was logged and regularly audited
> >4. Keys were regularly and in an automated fashion rotated, maybe even
> >   daily
> >
> > If such precautions are taken, it is their router and it is their
> > service, seems reasonable that Comcast should be able to log into
> > their router and change configs.
>
> ... such that the access of the Wifi Password which is likely stored in
> plain text on the router is accessed by Comcast in a secure manner and not
> stored in plain text in their internal databases.
>
> But I'm guessing probably it's just cached in plain text in their internal
> DBs.
>
> Get your own router if you're worried about your Wifi Password being known
> by Comcast. Or change to WPA2 Enterprise, but I'm guessing that isn't
> supported on the router...
>
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com
> http://www.angryox.com/
> ---
>

Re: Cellular backup connections

[K. Scott Helms]

I really can't believe I'm going to say this, but this has been a good
SD-WAN use case for us.


Scott Helms



On Fri, Dec 28, 2018 at 2:30 PM Aaron1  wrote:

> On the topic of static ip... as a Net Eng of an ISP, and seeing the pains
> that we have to endure with our static ip customers , I wonder if static ip
> customers actually inadvertently get less optimal treatment than more
> flexible, agile and dynamic ip customers ?
>
> I’m saying that since over the years as I have migrated from one router to
> another, from one technology Ethernet/IP, mpls/ip, it’s more difficult to
> move those static customers subnets around, and sometimes easier just to
> leave them on an old router where they’ve been for years.
>
> Aaron
>
> On Dec 28, 2018, at 12:32 PM, Jared Geiger  wrote:
>
> I found horrible routing with a static IP setup with T-Mobile. The device
> was located in Ashburn, outbound routing would go out via Dallas and
> inbound would come in via Seattle. So ping times and usability was rough.
> Tried it on the west coast and the same problem. T-Mobile support said this
> was by design and they couldn’t change it.
>
> I decided to switch to a regular consumer AT data sim without a static
> IP and set up a small router to initiate a VPN tunnel out to wherever I
> need it. It turns out to be cheaper and reliable for us.
>
> ~Jared Geiger
>
> On Fri, Dec 28, 2018 at 11:53 AM Ryan Wilkins  wrote:
>
>> You mention your connection is 4G.  On T-Mobile 4G is UMTS whereas LTE
>> is, well, LTE.  Are you really on UMTS (which I would expect to have much
>> crazier RTTs and jitter like you report) or did you mean LTE?
>>
>> Ryan
>>
>> > On Dec 28, 2018, at 7:06 AM, Dovid Bender  wrote:
>> >
>> > Hi All,
>> >
>> > I finally got around to setting up a cellular backup device in our new
>> POP. I am currently testing with T-Mobile where the cell signal strength is
>> at 80%. The connection is 4G. When SSH'ing in remotely the connection seems
>> rather slow. Ping times seem to be all over the place (for instance now I
>> am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is
>> that just cellular or is that more related to the provider and the location
>> where I am? I could in theory test with VZ and ATT as well. With Verizon
>> they charge $500.00 just to get a public IP and I want to avoid that if
>> possible.
>> >
>> > Thanks and sorry in advance if this is off topic.
>> >
>> >
>>
>>

Re: Enterprise GPON / Zhone Questions

[K. Scott Helms]

I'd say that any carrier grade GPON gear is way overkill for a LAN and
you're going to have to run single mode fiber to use the consumer grade
ONTs which is a big extra expense as few structured wiring companies do
single mode.  Second, Dasan Zhone is one of the vendors I'd absolutely
avoid and I've worked on numerous GPON OLTs (Adtran TA5000/3000, Calix C7,
E7, E3, and others).  Their configuration is problematic as you've found
out and they have a poor track record in security.

https://www.securityweek.com/over-million-dasan-routers-vulnerable-remote-hacking

Using third party optics is (with all the GPON vendors) a complete crap
shoot.  Sometimes they will work and suddenly a firmware update from the
OLT vendor comes along and they no longer work.  Other times they don't
work at all or are very unreliable.

GPON is a standard, but in North America the vendors have largely not been
forced to do interoperability and it's very lacking.  Compare that to
Europe where the Fritzbox is one of the most popular ONTs.

Finally, as many have said I cannot see any scenario where building GPON
will be as cost effective, reliable, or performant as simply building out a
switched Ethernet network over fiber.


On Tue, Dec 11, 2018 at 10:53 AM Nick Bogle  wrote:

> Hello fellow NANOG members :)
>
> Let me start with a little bit of background, my day job is a Network
> Engineer for a local university where we have primarily a Cisco environment
> from phones to switching to routing, etc. Before my time, we hired a
> contractor to design a GPON LAN system for a new building as a cost saving
> measure (though I am not sure how successful that was).
>
> Either way, the contractor is about to hand the system off to us, and we
> have gone through the training and such, and I feel confident in my ability
> to manage the system, but we have a few questions that the manufacturer of
> our equipment and our contractor didn't really want to answer. We are
> currently using a Dasan Zhone MXK-F1419 with several different downstream
> ONT models (all Zhone).
>
> -We would like to consider use of 3rd party GPON B+ Optics on the
> linecards to add redundancy to the splitter (as the cost of 1st party are
> too high). Does anyone have experience with 3rd party
> vendors/compatibility/stability issues? We were told they theoretically
> should work and just throw a log event, but it hasn't been tested. If so,
> what vendors would you recommend? So far all we've really seen are Ubiquiti
> and Fiberstore optics.
>
> -As GPON is a standard itself, I'm aware interoperability between OLT and
> ONT vendors is heavily limited.. Does anyone have any experience using say,
> Zhone ONT's with a different model OLT, or Zhone ONT's with a different
> model OLT? I've heard word that Zhone ONT's may be able to work with Nokia
> OLT's but it's technically not supported.
>
> -We've already experienced some pretty big stability issues (have replaced
> 1 line card 5 times..), our contractor is saying it's just because we were
> a pretty early adopter of this line and that they've fixed it and fixed
> internal policies to add additional QA and testing before shipping to
> customers. Does anyone have any experience with working with Zhone and
> their overall stability of components?
>
> - Any other thoughts/gotchas/advice for deploying a GPON environment in a
> corporate LAN? (or about deploying a Zhone solution) It's pretty service
> provider oriented, and is incredible noticeable in the CLI.
>
> -Is anyone familiar with Zhone CLI? The apparent lack of any "show"
> configuration commands is infuriating.
>
>
> Feel free to contact me offlist if you have any pertinent info that you
> don't want on the list.
>
> Thanks,
>
> Nick Bogle
> n...@bogle.se
>

Re: Proving Gig Speed

[K. Scott Helms]

> Peering isn't the problem. Proximity to content is.
>
> Netflix, Google, Akamai and a few others have presence in Africa already.
> So those aren't the problem (although for those currently in Africa, not
> all of the services they offer globally are available here - just a few).
>
> A lot of user traffic is not video streaming, so that's where a lot of
> work is required. In particular, cloud and gaming operators are the ones
> causing real pain.
>
> All the peering in the world doesn't help if the latency is well over
> 100ms+. That's what we need to fix.
>
> Mark.
>

Mark,

I agree completely, I'm working on a paper right now for a conference
(waiting on Wireshark to finish with my complex filter at the moment) that
shows what's happening with gaming traffic.  What's really interesting is
how gaming is changing and within the next few years I do expect a lot of
games to move into the remote rendering world.  I've tested several and the
numbers are pretty substantial.  You need to have <=30 ms of latency to
sustain 1080p gaming and obviously jitter and packet loss are also
problematic.  The traffic is also pretty impressive with spikes of over 50
mbps down and sustained averages over 21 mbps.  Upstream traffic isn't any
more of an issue than "normal" online gaming.  Nvidia, Google, and a host
of start ups are all in the mix with a lot of people predicting Sony and
Microsoft will be (or are already) working on pure cloud consoles.

Scott Helms

Re: Proving Gig Speed

[K. Scott Helms]

Mark,

I am glad I don't have your challenges :)

What's the Netflix (or other substantial OTT video provider) situation for
direct peers?  It's pretty easy and cheap for North American operators to
get settlement free peering to Netflix, Amazon, Youtube and others but I
don't know what that looks like in Africa.

Scott Helms

On Wed, Jul 18, 2018 at 10:00 AM Mark Tinka  wrote:

>
>
> On 18/Jul/18 15:41, K. Scott Helms wrote:
>
>
>
> That's why I vastly prefer stats from the actual CDNs and content
> providers that aren't generated by speed tests.  They're generated by
> measuring the actual performance of the service they deliver.  Now, that
> won't prevent burden shifting, but it does get rid of a lot of the problems
> you bring up.  Youtube for example wouldn't rate a video stream as good if
> the packet loss were high because it's actually looking at the bit rate of
> successfully delivered encapsulated video frames I _think_ the same is true
> of Netflix though they also offer a real time test as well which frankly
> isn't as helpful for monitoring but getting a quick test to the Netflix
> node you'd normally use can be nice in some cases.
>
>
> Agreed.
>
> In our market, we've generally not struggled with users and their
> experience for services hosted locally in-country.
>
> So in addition to providing good tools for operators and eyeballs to
> measure experience, the biggest win will come from the content folk and
> CDN's getting their services inside our market.
>
> Mark.
>
>

Re: Proving Gig Speed

[K. Scott Helms]

That seems only to be for direct peers Mike.

On Wed, Jul 18, 2018 at 9:53 AM Mike Hammett  wrote:

> https://isp.google.com
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "K. Scott Helms" 
> To: "Mike Hammett" 
> Cc: "NANOG list" 
> Sent: Wednesday, July 18, 2018 8:45:22 AM
> Subject: Re: Proving Gig Speed
>
>
> Mike,
>
> What portal would that be? Do you have a URL?
>
>
> On Wed, Jul 18, 2018 at 9:25 AM Mike Hammett < na...@ics-il.net > wrote:
>
>
> Check your Google portal for more information as to what Google can do
> with BGP Communities related to reporting.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "K. Scott Helms" < kscott.he...@gmail.com >
> To: "mark tinka" < mark.ti...@seacom.mu >
> Cc: "NANOG list" < nanog@nanog.org >
> Sent: Wednesday, July 18, 2018 7:40:31 AM
> Subject: Re: Proving Gig Speed
>
> Agreed, and it's one of the fundamental problems that a speed test is (and
> can only) measure the speeds from point A to point B (often both inside
> the
> service provider's network) when the customer is concerned with traffic to
> and from point C off in someone else's network altogether. It's one of the
> reasons that I think we have to get more comfortable and more
> collaborative
> with the CDN providers as well as the large sources of traffic. Netflix,
> Youtube, and I'm sure others have their own consumer facing performance
> testing that is _much_ more applicable to most consumers as compared to
> the
> "normal" technician test and measurement approach or even the service
> assurance that you get from normal performance monitoring. What I'd really
> like to see is a way to measure network performance from the CO/head
> end/PoP and also get consumer level reporting from these kinds of
> services. If Google/Netflix/Amazon Video/$others would get on board with
> this idea it would make all our lives simpler.
>
> Providing individual users stats is nice, but if these guys really want to
> improve service it would be great to get aggregate reporting by ASN. You
> can get a rough idea by looking at your overall graph from Google, but
> it's
> lacking a lot of detail and there's no simple way to compare that to a
> head
> end/CO test versus specific end users.
>
> https://www.google.com/get/videoqualityreport/
> https://fast.com/#
>
>
>
> On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka < mark.ti...@seacom.mu >
> wrote:
>
> >
> >
> > On 18/Jul/18 14:00, K. Scott Helms wrote:
> >
> >
> > That's absolutely a concern Mark, but most of the CPE vendors that
> support
> > doing this are providing enough juice to keep up with their max
> > forwarding/routing data rates. I don't see 10 Gbps in residential
> Internet
> > service being normal for quite a long time off even if the port itself
> is
> > capable of 10Gbps. We have this issue today with commercial customers,
> but
> > it's generally not as a much of a problem because the commercial CPE get
> > their usage graphed and the commercial CPE have more capabilities for
> > testing.
> >
> >
> > I suppose the point I was trying to make is when does it stop being
> > feasible to test each and every piece of bandwidth you deliver to a
> > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or
> 3.2Gbps,
> > or 5.1Gbps... basically, the rabbit hole.
> >
> > Like Saku, I am more interested in other fundamental metrics that could
> > impact throughput such as latency, packet loss and jitter. Bandwidth,
> > itself, is easy to measure with your choice of SNMP poller + 5 minutes.
> But
> > when you're trying to explain to a simple customer buying 100Mbps that a
> > break in your Skype video cannot be diagnosed with a throughput speed
> test,
> > they don't/won't get it.
> >
> > In Africa, for example, customers in only one of our markets are so
> > obsessed with speed tests. But not to speed test servers that are
> > in-country... they want to test servers that sit in Europe, North
> America,
> > South America and Asia-Pac. With the latency averaging between 140ms -
> > 400ms across all of those regions from source, the amount of energy
> spent
> > explaining to customers that there is no way you can saturate your
> > de

Re: Proving Gig Speed

[K. Scott Helms]

Mike,

What portal would that be?  Do you have a URL?

On Wed, Jul 18, 2018 at 9:25 AM Mike Hammett  wrote:

> Check your Google portal for more information as to what Google can do
> with BGP Communities related to reporting.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ----- Original Message -
>
> From: "K. Scott Helms" 
> To: "mark tinka" 
> Cc: "NANOG list" 
> Sent: Wednesday, July 18, 2018 7:40:31 AM
> Subject: Re: Proving Gig Speed
>
> Agreed, and it's one of the fundamental problems that a speed test is (and
> can only) measure the speeds from point A to point B (often both inside
> the
> service provider's network) when the customer is concerned with traffic to
> and from point C off in someone else's network altogether. It's one of the
> reasons that I think we have to get more comfortable and more
> collaborative
> with the CDN providers as well as the large sources of traffic. Netflix,
> Youtube, and I'm sure others have their own consumer facing performance
> testing that is _much_ more applicable to most consumers as compared to
> the
> "normal" technician test and measurement approach or even the service
> assurance that you get from normal performance monitoring. What I'd really
> like to see is a way to measure network performance from the CO/head
> end/PoP and also get consumer level reporting from these kinds of
> services. If Google/Netflix/Amazon Video/$others would get on board with
> this idea it would make all our lives simpler.
>
> Providing individual users stats is nice, but if these guys really want to
> improve service it would be great to get aggregate reporting by ASN. You
> can get a rough idea by looking at your overall graph from Google, but
> it's
> lacking a lot of detail and there's no simple way to compare that to a
> head
> end/CO test versus specific end users.
>
> https://www.google.com/get/videoqualityreport/
> https://fast.com/#
>
>
>
> On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka  wrote:
>
> >
> >
> > On 18/Jul/18 14:00, K. Scott Helms wrote:
> >
> >
> > That's absolutely a concern Mark, but most of the CPE vendors that
> support
> > doing this are providing enough juice to keep up with their max
> > forwarding/routing data rates. I don't see 10 Gbps in residential
> Internet
> > service being normal for quite a long time off even if the port itself
> is
> > capable of 10Gbps. We have this issue today with commercial customers,
> but
> > it's generally not as a much of a problem because the commercial CPE get
> > their usage graphed and the commercial CPE have more capabilities for
> > testing.
> >
> >
> > I suppose the point I was trying to make is when does it stop being
> > feasible to test each and every piece of bandwidth you deliver to a
> > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or
> 3.2Gbps,
> > or 5.1Gbps... basically, the rabbit hole.
> >
> > Like Saku, I am more interested in other fundamental metrics that could
> > impact throughput such as latency, packet loss and jitter. Bandwidth,
> > itself, is easy to measure with your choice of SNMP poller + 5 minutes.
> But
> > when you're trying to explain to a simple customer buying 100Mbps that a
> > break in your Skype video cannot be diagnosed with a throughput speed
> test,
> > they don't/won't get it.
> >
> > In Africa, for example, customers in only one of our markets are so
> > obsessed with speed tests. But not to speed test servers that are
> > in-country... they want to test servers that sit in Europe, North
> America,
> > South America and Asia-Pac. With the latency averaging between 140ms -
> > 400ms across all of those regions from source, the amount of energy
> spent
> > explaining to customers that there is no way you can saturate your
> > delivered capacity beyond a couple of Mbps using Ookla and friends is
> > energy I could spend drinking wine and having a medium-rare steak,
> instead.
> >
> > For us, at least, aside from going on a mass education drive in this
> > particular market, the ultimate solution is just getting all that
> content
> > localized in-country or in-region. Once that latency comes down and the
> > resources are available locally, the whole speed test debacle will
> easily
> > fall away, because the source of these speed tests is simply how
> physically
> > far the content is. Is this an easy task - hell no; but slamming your
> head
> > against a wall over and over is no fun either.
> >
> > Mark.
> >
>
>

Re: Proving Gig Speed

[K. Scott Helms]

On Wed, Jul 18, 2018 at 9:01 AM Mark Tinka  wrote:

>
> Personally, I don't think the content networks and CDN's should focus on
> developing yet-another-speed-test-server, because then they are just
> pushing the problem back to the ISP. I believe they should better spend
> their time:
>
>- Delivering as-near-to 100% of all of their services to all regions,
>cities, data centres as they possibly can.
>
>
>- Providing tools for network operators as well as their consumers
>that are biased toward the expected quality of experience, rather than how
>fast their bandwidth is. A 5Gbps link full of packet loss does not a
>service make - but what does that translate into for the type of service
>the content network or CDN is delivering?
>
> Mark.
>
That's why I vastly prefer stats from the actual CDNs and content providers
that aren't generated by speed tests.  They're generated by measuring the
actual performance of the service they deliver.  Now, that won't prevent
burden shifting, but it does get rid of a lot of the problems you bring
up.  Youtube for example wouldn't rate a video stream as good if the packet
loss were high because it's actually looking at the bit rate of
successfully delivered encapsulated video frames I _think_ the same is true
of Netflix though they also offer a real time test as well which frankly
isn't as helpful for monitoring but getting a quick test to the Netflix
node you'd normally use can be nice in some cases.

Re: Proving Gig Speed

[K. Scott Helms]

Agreed, and it's one of the fundamental problems that a speed test is (and
can only) measure the speeds from point A to point B (often both inside the
service provider's network) when the customer is concerned with traffic to
and from point C off in someone else's network altogether.  It's one of the
reasons that I think we have to get more comfortable and more collaborative
with the CDN providers as well as the large sources of traffic.  Netflix,
Youtube, and I'm sure others have their own consumer facing performance
testing that is _much_ more applicable to most consumers as compared to the
"normal" technician test and measurement approach or even the service
assurance that you get from normal performance monitoring.  What I'd really
like to see is a way to measure network performance from the CO/head
end/PoP and also get consumer level reporting from these kinds of
services.  If Google/Netflix/Amazon Video/$others would get on board with
this idea it would make all our lives simpler.

Providing individual users stats is nice, but if these guys really want to
improve service it would be great to get aggregate reporting by ASN.  You
can get a rough idea by looking at your overall graph from Google, but it's
lacking a lot of detail and there's no simple way to compare that to a head
end/CO test versus specific end users.

https://www.google.com/get/videoqualityreport/
https://fast.com/#



On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka  wrote:

>
>
> On 18/Jul/18 14:00, K. Scott Helms wrote:
>
>
> That's absolutely a concern Mark, but most of the CPE vendors that support
> doing this are providing enough juice to keep up with their max
> forwarding/routing data rates.  I don't see 10 Gbps in residential Internet
> service being normal for quite a long time off even if the port itself is
> capable of 10Gbps.  We have this issue today with commercial customers, but
> it's generally not as a much of a problem because the commercial CPE get
> their usage graphed and the commercial CPE have more capabilities for
> testing.
>
>
> I suppose the point I was trying to make is when does it stop being
> feasible to test each and every piece of bandwidth you deliver to a
> customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or 3.2Gbps,
> or 5.1Gbps... basically, the rabbit hole.
>
> Like Saku, I am more interested in other fundamental metrics that could
> impact throughput such as latency, packet loss and jitter. Bandwidth,
> itself, is easy to measure with your choice of SNMP poller + 5 minutes. But
> when you're trying to explain to a simple customer buying 100Mbps that a
> break in your Skype video cannot be diagnosed with a throughput speed test,
> they don't/won't get it.
>
> In Africa, for example, customers in only one of our markets are so
> obsessed with speed tests. But not to speed test servers that are
> in-country... they want to test servers that sit in Europe, North America,
> South America and Asia-Pac. With the latency averaging between 140ms -
> 400ms across all of those regions from source, the amount of energy spent
> explaining to customers that there is no way you can saturate your
> delivered capacity beyond a couple of Mbps using Ookla and friends is
> energy I could spend drinking wine and having a medium-rare steak, instead.
>
> For us, at least, aside from going on a mass education drive in this
> particular market, the ultimate solution is just getting all that content
> localized in-country or in-region. Once that latency comes down and the
> resources are available locally, the whole speed test debacle will easily
> fall away, because the source of these speed tests is simply how physically
> far the content is. Is this an easy task - hell no; but slamming your head
> against a wall over and over is no fun either.
>
> Mark.
>

Re: Proving Gig Speed

[K. Scott Helms]

That's absolutely a concern Mark, but most of the CPE vendors that support
doing this are providing enough juice to keep up with their max
forwarding/routing data rates.  I don't see 10 Gbps in residential Internet
service being normal for quite a long time off even if the port itself is
capable of 10Gbps.  We have this issue today with commercial customers, but
it's generally not as a much of a problem because the commercial CPE get
their usage graphed and the commercial CPE have more capabilities for
testing.

Scott Helms


On Tue, Jul 17, 2018 at 8:11 AM Mark Tinka  wrote:

>
>
> On 17/Jul/18 14:07, K. Scott Helms wrote:
>
>
> That's absolutely true, but I don't see any real alternatives in some
> cases.  I've actually built automated testing into some of the CPE we've
> deployed and that works pretty well for some models but other devices don't
> seem to be able to fill a ~500 mbps link.
>
>
> So what are you going to do when 10Gbps FTTH into the home becomes the
> norm?
>
> Perhaps laptops and servers of the time won't even see this as a rounding
> error :-\...
>
> Mark.
>

Re: Proving Gig Speed

[K. Scott Helms]

That's absolutely true, but I don't see any real alternatives in some
cases.  I've actually built automated testing into some of the CPE we've
deployed and that works pretty well for some models but other devices don't
seem to be able to fill a ~500 mbps link.


On Tue, Jul 17, 2018 at 8:03 AM Mark Tinka  wrote:

>
>
> On 16/Jul/18 22:31, Carlos Alcantar wrote:
>
> > It's a complete rabbit hole...
>
> Couldn't have said it better myself!
>
> Mark.
>

Re: Impacts of Encryption Everywhere (any solution?)

[K. Scott Helms]

Mark,

A couple of things, first that kind of utilization isn't feasible once
penetration rates in dense areas reach certain levels.  There's a reason
that NTT Docomo moved more than 70% of their data traffic to the 3.5 GHz
band and that reason is that there's not (nor will there be) enough
wireless spectrum to meet the needs of everyone with licensed space.  (That
same use case is why all the big North American providers are looking at
CBRS.) Further, 4G/5G is going to have trouble scaling to the kinds of
network demands going forward, again especially in dense areas.  While it's
certainly possible today to stream unicast video over LTE and will (for a
while) even more feasible over 5G the physics simply aren't with the
wireless world.

I'd say that your example of poor DSL performance isn't unique, it happens
in some spots in the US, but in general wired performance has much higher
individual and even higher aggregate capacities *when correctly deployed.  *I
doubt your hotel example is a poor deployment though, it's more likely that
the hotel owners are under paying for both the WAN connection and the WiFi
infrastructure.


On Wed, May 30, 2018 at 1:01 PM Mark Tinka  wrote:

>
>
> On 30/May/18 17:11, McBride, Mack wrote:
>
> > In high density urban areas last mile infrastructure (mostly copper) is
> considerably better than 4G.
> > Localized carrier powered wifi is good as well but it is not and should
> not be confused with 4G.
>
> I think it depends on what it is you're trying to do. If your
> application is linear IPTV streaming into your home, that probably isn't
> a great idea for any kind of non-wired media. On the other hand, in
> South Africa, where I live, it is routine to deliver video streaming
> services (Netflix, Youtube, ShowMax, e.t.c.) to one's home over 4G/LTE,
> to the extent that the service providers have special data plans that
> support these kinds of use-cases.
>
> In South Africa, I generally find wi-fi in the hotels to be pretty bad,
> as the majority of them tend to be on ADSL backhaul, which averages
> between 1Mbps - 4Mbps to support several dozen or more rooms. A few
> hotels have migrated to fibre, but between guessing what last mile
> they're on and how they operate the wi-fi network, I ALWAYS prefer to
> tether my iPhone to my laptop and work when I'm on the road within the
> country. In all major cities, my 3G/4G performs a lot more reliably,
> better and predictably than most cafe, hotel or mall wi-fi. I don't even
> bother when hotels offer their wi-fi vouchers upon check-in.
>
> With my 4G services (Vodacom and MTN), I can average between 30Mbps -
> 55Mbps when tethering, and that's plenty enough for me. I have a decent
> monthly data plan that I don't have to worry about running out. Of
> course, performance isn't as great if you're in a remote part of the
> country, but that's not unique to South Africa.
>
> Mark.
>

Re: Opinions on intent-based networking

[K. Scott Helms]

A substantial percentage, perhaps 100%, of the use case can be accomplished
using micro-segmentation.

On Tue, May 29, 2018 at 2:33 PM LF OD  wrote:

> Been following the articles on "intent-based" networking from Cisco and
> other vendors for a couple years now, and I have a basic grasp of the
> concept of "define your goals/outcomes and automation will make it so", but
> I do not know the practical applications of it or how you are supposed to
> convey your "intent". However, $dayjob is a medium-sized enterprise and
> looking at a potential refresh in the upcoming budget.
>
>
> So... do any of you at ISPs, Cloud Providers, or Enterprises have any
> hands-on experience with "intent-based" networking products? If so, could
> you please provide some info on what caused you to look at it, who did you
> look at, why did you choose whoever you chose, and is it working out for
> you?
>
>
> If you looked at it very closely and decided not to bother with it, I'd
> also be interested on your take. At $dayjob we have been adopting
> automation at the application and workload level, but there hasn't been
> much need for it at the infrastructure level. However, if we can improve
> the services we offer while refreshing that infrastructure, it wouldn't
> hurt - depending on cost of course.
>
>
> Thanks in advance.
>
> LF0D
>

Re: GDPR outside Europe, was Whois vs GDPR, latest news

[K. Scott Helms]

*" PS: For anyone who came into the middle of this argument, my point
isthat if you have no EU nexus, the realistic chances of the EU
takingaction against you round to zero.  If you do have EU nexus, you
betterbehave."*

I'd say this is accurate with a few caveats and most of those won't apply
to NANOG folks.  One, if you or your company is involved in direct
marketing then you'd better pay attention now even if you don't
intentionally market to people in the EU.  Two, if you work on sensitive
PII (by the GDPR definitions) and you may have EU data subjects' PII.
Three, if you or your company are making public statements about GDPR not
applying to you or making false statements publicly about how your opt out
set up is GDPR compliant (when it can't be).

When I first was involved with international contracts we had a series of
meetings with our executives and legal.  The first thing we heard from
legal were things like, "your contracts aren't enforceable in Europe or
Asia".  When we dived into those statements what we found was that was
practically true, because enforcing them required us to go down one of two
(both expensive) pathways.  Establish a corporate identify in all the
places we wanted to do business and then we could more easily sue in the
local court system where our customers were located _or_ we could sue in US
court and then (provided we won) take that US ruling to the local courts
with jurisdiction over the customer in question.  Both were entirely
possible from a legal standpoint, but neither were practical since the cost
of taking either path would greatly exceed the value of the contract in
question.  Instead of doing that we simply set things up so that we can
quickly turn off services and we billed a month in advance rather than post
billing the way we did in North America.

What I'm getting at is that international enforcement of decisions is
expensive and while the EU has a lot of resources, lawyers, and money
they're still going to be prioritizing their "target" selection.  They're
definitely (as we see from the Facebook fine) going after the big, and in
their minds, egregious abusers of privacy.  Unless you or your company is
very large, international in nature, or doing something they'd consider
very abusive then you're not likely to be at the top of that list.  Having
said that, once things shake out and the big fish are all either compliant
or in court then the regulators will start looking down list.

In fairness, the regulators I spoke with emphasized that they're not "head
hunting" (their words) and that don't want to harm companies that might
inadvertently be violating GDPR in small ways.  I expect that many more
warning letters will be sent than actual fines or regulatory actions this
year.


On Thu, May 24, 2018 at 6:31 PM John Levine  wrote:

> In article <0bb31bbb-388d-4832-85dd-30c01c187...@jeffmurphy.org> you
> write:
> >There’s speculation that enforcement could occur via the FTC Privacy
> Shield program.
>
> Privacy Shield is entirely optional. Joining it requires a lot of
> paperwork and a substantial administrative fee.  If you don't do all
> that, it doesn't apply to you.  Please see my previous comment about
> people who think they understand the GDPR vs. people who actually do.
>
> https://www.privacyshield.gov/welcome
>
> Also, Privacy Shield is a retread of the Safe Harbour deal which EU
> courts invalidated in 2015.  Max Schrems, the guy who filed the case
> against Safe Harbour, has filed a similar suit against Privacy Shield,
> with Facebook as the defendant.  I wouldn't bet a lot on Privacy
> Shield lasting any better than Safe Harbour did.
>
>
> https://techcrunch.com/2018/04/13/privacy-shield-now-facing-questions-via-legal-challenge-to-facebook-data-flows/
>
> R's,
> John
>
> PS: For anyone who came into the middle of this argument, my point is
> that if you have no EU nexus, the realistic chances of the EU taking
> action against you round to zero.  If you do have EU nexus, you better
> behave.
>

Re: Whois vs GDPR, latest news

[K. Scott Helms]

 Anne,

While I was re-reading some of the emails last night I realized that I
mischaracterized your description here, *"You may accuse me of being a
lawyer here (and rightly so :-) ), but "in", as in "in the Union" (which is
the actual language) is very much open to interpretation.  In a judicial
system where lawsuits have turned on  - I kid you not - the interpretation
of what a comma meant, I can almost guarantee you that "in the Union" is
going to get interpreted through lawsuits, and it is absolutely not outside
the realm of possibility that a U.S. citizen visiting in the EU will bring
a lawsuit based on something happening with their PII while they were "in
the Union".*

I didn't make it clear that you were suggesting that some would make this
claim rather than you making that claim.  Mea culpa :)

Our counselors made it clear (as did the regulators I was able to ask) that
short term visits weren't intended to be covered *in their opinion.*  There
are and will be many questions that won't be fully answered until
adjudicated or more precise language is used to make the meaning clear.
 Juhan Lepassaar (Head of VP Ansip Cabinet, European Commission) was one of
the speakers and we were able to ask questions of him.  It looks like the
video of one of the presentations I was at is now publicly available and I
encourage those with questions to watch it.

https://www.rsaconference.com/speakers/juhan-lepassaar

*" Actually, GDPR specifically requires processors to include statements of
compliance right in their contracts;  we also strongly recommend that
controllers insist on indemnification clauses in their contracts with
processors, because if the processor screws up and there is a breach, the
_controller_ can also be held liable, and the financial penalties in GDPR
are very stiff."*

Yep, this is better (clearer) wording than what I used and is absolutely
correct.



On Thu, May 24, 2018 at 10:21 AM Anne P. Mitchell Esq. <amitch...@isipp.com>
wrote:

>
>
> > On May 23, 2018, at 7:18 PM, K. Scott Helms <kscott.he...@gmail.com>
> wrote:
> >
> > Anything that can tie back to an individual data subject is PII, that
> means email addresses, names in combination with addresses or phone
> numbers, finger prints, or even insufficiently abstracted internal ID
> numbers/codes.
>
> Don't forget IP addresses, as part of the wonderfully vague "online
> identifiers".
>
> > Notice I didn't say EU citizen there, that's because the law and
> regulations (GDPR consists of both) intentionally cover any natural person
> in any of the 28 EU nations including the citizens of non-EU nations.
> >  I don't go as far as I think Anne was suggesting, in that someone in EU
> airspace who sent an email or made a purchase is now suddenly an EU data
> subject.
>
> You may accuse me of being a lawyer here (and rightly so :-) ), but "in",
> as in "in the Union" (which is the actual language) is very much open to
> interpretation.  In a judicial system where lawsuits have turned on  - I
> kid you not - the interpretation of what a comma meant, I can almost
> guarantee you that "in the Union" is going to get interpreted through
> lawsuits, and it is absolutely not outside the realm of possibility that a
> U.S. citizen visiting in the EU will bring a lawsuit based on something
> happening with their PII while they were "in the Union".
>
> > Any company that is covered by the GDPR must be extremely careful that
> any company they do business with is also compliant if that company will
> have access or act as a data processor.  That means that if you are a US
> company that has US only customers, but some of your customers have
> employees that are US citizens but who live in an EU nation then they are
> bound to only use providers that are GDPR compliant.  Now, this will result
> in contractual disputes and/or loss of business rather than having EU
> regulators fine your company directly.  The end result is that many many
> many companies that don't sell or market to the EU are finding themselves
> needing to comply in the same way that companies that sell services to
> medical companies often have to follow HIPAA  (and be audited) even though
> they provide medical services themselves.
> >
>
> Actually, GDPR specifically requires processors to include statements of
> compliance right in their contracts;  we also strongly recommend that
> controllers insist on indemnification clauses in their contracts with
> processors, because if the processor screws up and there is a breach, the
> _controller_ can also be held liable, and the financial penalties in GDPR
> are very stiff.
>
> Anne
>
> Anne P. Mitchell,
> Attorney at Law
> CEO/President,
>

Re: Whois vs GDPR, latest news

[K. Scott Helms]

Anne,

Yep, if you're doing a decent job around securing data then you don't have
much to be worried about on that side of things.  The problem for most
companies is that GDPR isn't really a security law, it's a privacy law (and
set of regulations).  That's where it's hard because there are a limited
number of ways you can, from the EU's standpoint, lawfully process
someone's PII.  Things like opting out and blanket agreements to use all of
someone's data for any reason a company may want are specifically
prohibited.  Even companies that don't intentionally sell into the EU (or
the UK) can find themselves dealing with this if they have customers with
employees in the EU.

On Wed, May 23, 2018 at 12:29 PM, Anne P. Mitchell Esq.  wrote:

>
>
> > On May 23, 2018, at 10:21 AM, Daniel Brisson  wrote:
> >
> >> Also, don't forget the private right of action.  Anyone can file
> anything in the U.S. courts... you  may get it dismissed (although then
> again you may not) but either way, it's going to be time and money out of
> your pocket fighting it.  MUCH better to just get compliant than to end up
> a test case.
> >
> > Isn't "better" a factor of how much it costs to become compliant with
> GPDR?  I'm no expert, but some of the things I've heard sounded not trivial
> to implement (read potentially BIG investment).
> >
> > -dan
>
> In our experience, orgs that are already following all industry best
> practices are, generally, at least 70% of the way to becoming compliant
> already.   Where it can get expensive for the ones who aren't is in
> hardening their systems to provide for better security/privacy.  U.S.
> companies are used to being able to drink at the firehose of data that is
> collected here in the U.S., and use it however they want.. this is the real
> major change.  I suppose you could say it's expensive in that it is
> reducing the ways they can monetize that data.
>
> Anne
>
> Anne P. Mitchell,
> Attorney at Law
> CEO/President,
> SuretyMail Email Reputation Certification and Inbox Delivery Assistance
> GDPR Compliance Consultant
> GDPR Compliance Certification
> http://www.SuretyMail.com/
> http://www.SuretyMail.eu/
>
> Attorney at Law / Legislative Consultant
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
> Author: The Email Deliverability Handbook
> Legal Counsel: The CyberGreen Institute
> Legal Counsel: The Earth Law Center
> Member, California Bar Cyberspace Law Committee
> Member, Colorado Cybersecurity Consortium
> Member, Board of Directors, Asilomar Microcomputer Workshop
> Member, Advisory Board, Cause for Awareness
> Member, Elevations Credit Union Member Council
> Former Chair, Asilomar Microcomputer Workshop
> Ret. Professor of Law, Lincoln Law School of San Jose
>
> Available for consultations by special arrangement.
> amitch...@isipp.com | @AnnePMitchell
> Facebook/AnnePMitchell  | LinkedIn/in/annemitchell
>
>

Re: Whois vs GDPR, latest news

[K. Scott Helms]

Yeah, that's not accurate.  US organizations sue EU organizations in US
courts (and vice versus) on a regular basis but have EU courts collect the
damages.  Congress can carve out an exemption, but I haven't heard of an
effort in that direction getting started yet.  In the absence of a
legislative exemption the EU regulators can absolutely sue a US entity in
US civil courts and get a ruling based on EU laws and regulations.

Here's a completely unrelated civil case, on libel, that references the
bilateral enforcement and how NY state carved out an exemption.

https://www.npr.org/sections/parallels/2015/03/21/394273902/on-libel-and-the-law-u-s-and-u-k-go-separate-ways

Scott Helms

http://twitter.com/kscotthelms


On Wed, May 23, 2018 at 11:56 AM, Owen DeLong <o...@delong.com> wrote:

> Not really. If you don’t offer services to EU persons, then you are right.
> However, due to treaties signed by the US and other countries, many places
> outside the EU are subject to GDPR overreach.
>
> Owen
>
>
> > On May 23, 2018, at 05:36, Mike Hammett <na...@ics-il.net> wrote:
> >
> > If you don't have operations in the EU, you can not so politely tell the
> EU to piss off.
> >
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions
> > http://www.ics-il.com
> >
> > Midwest-IX
> > http://www.midwest-ix.com
> >
> > - Original Message -
> >
> > From: "Matthew Kaufman" <matt...@matthew.at>
> > To: "Fletcher Kittredge" <fkitt...@gwi.net>
> > Cc: "NANOG list" <nanog@nanog.org>
> > Sent: Monday, May 21, 2018 8:07:15 PM
> > Subject: Re: Whois vs GDPR, latest news
> >
> >> On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge <fkitt...@gwi.net>
> wrote:
> >>
> >> What about my right to not have this crap on NANOG?
> >>
> >
> >
> > What about the likely truth that if anyone from Europe mails the list,
> then
> > every mail server operator with subscribers to the list must follow the
> > GDPR Article 14 notification requirements, as the few exceptions appear
> to
> > not apply (unless you’re just running an archive).
> >
> > Matthew
> >
>
>

Re: Whois vs GDPR, latest news

[K. Scott Helms]

Of course not, but do you really want to be sued?  Even if the US courts
decline to accept GDPR cases, which is not at all a given since we have a
long history of bilateral enforcement, it costs money to deal with and I
don't want to worry that I'm going to fly one day to a country that will
enforce civil penalties.

While I don't tell most people or companies to worry if they only do
business in the US I also don't think it's a good idea to simply thumb your
nose at the EU regulators.  Some North American direct marketing and data
collection firms are definitely going to get a rude, and expensive,
awakening despite not having any EU operations.

On Wed, May 23, 2018 at 8:49 AM, Mike Hammett <na...@ics-il.net> wrote:

> *shrugs* Me hurting the EU's feelings is rather low on the list of things
> I care about.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ----- Original Message -
>
> From: "K. Scott Helms" <kscotthe...@gmail.com>
> To: "Mike Hammett" <na...@ics-il.net>
> Cc: "NANOG list" <nanog@nanog.org>
> Sent: Wednesday, May 23, 2018 7:46:19 AM
> Subject: Re: Whois vs GDPR, latest news
>
>
> Sadly this isn't true. While I doubt the EU regulators are going to come
> head hunting for companies any time soon they do have mechanisms in place
> to sanction companies who don't do business in the EU and the scope is
> clearly intended to reach where ever the data of EU natural persons is
> being held.
>
>
> https://gdpr-info.eu/art-3-gdpr/
>
>
>
> I asked one of the EU regulators at RSA how they intended to enforce GDPR
> violations on businesses that don't operate in their jurisdiction and
> without hesitation he told me they'd use civil courts to sue the offending
> companies.
>
>
> On Wed, May 23, 2018 at 8:36 AM, Mike Hammett < na...@ics-il.net > wrote:
>
>
> If you don't have operations in the EU, you can not so politely tell the
> EU to piss off.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Matthew Kaufman" < matt...@matthew.at >
> To: "Fletcher Kittredge" < fkitt...@gwi.net >
> Cc: "NANOG list" < nanog@nanog.org >
> Sent: Monday, May 21, 2018 8:07:15 PM
> Subject: Re: Whois vs GDPR, latest news
>
>
>
> On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge < fkitt...@gwi.net >
> wrote:
>
> > What about my right to not have this crap on NANOG?
> >
>
>
> What about the likely truth that if anyone from Europe mails the list,
> then
> every mail server operator with subscribers to the list must follow the
> GDPR Article 14 notification requirements, as the few exceptions appear to
> not apply (unless you’re just running an archive).
>
> Matthew
>
>
>
>
>
>

Re: Whois vs GDPR, latest news

[K. Scott Helms]

Sadly this isn't true.  While I doubt the EU regulators are going to come
head hunting for companies any time soon they do have mechanisms in place
to sanction companies who don't do business in the EU and the scope is
clearly intended to reach where ever the data of EU natural persons is
being held.

https://gdpr-info.eu/art-3-gdpr/

I asked one of the EU regulators at RSA how they intended to enforce GDPR
violations on businesses that don't operate in their jurisdiction and
without hesitation he told me they'd use civil courts to sue the offending
companies.

On Wed, May 23, 2018 at 8:36 AM, Mike Hammett  wrote:

> If you don't have operations in the EU, you can not so politely tell the
> EU to piss off.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Matthew Kaufman" 
> To: "Fletcher Kittredge" 
> Cc: "NANOG list" 
> Sent: Monday, May 21, 2018 8:07:15 PM
> Subject: Re: Whois vs GDPR, latest news
>
> On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge 
> wrote:
>
> > What about my right to not have this crap on NANOG?
> >
>
>
> What about the likely truth that if anyone from Europe mails the list,
> then
> every mail server operator with subscribers to the list must follow the
> GDPR Article 14 notification requirements, as the few exceptions appear to
> not apply (unless you’re just running an archive).
>
> Matthew
>
>

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[K. Scott Helms]

They use separate service flows and layer 3 interfaces (usually) in DOCSIS
networks but they often use the same DNS infrastructure which is why I
piped up.

Scott Helms


On Mar 2, 2018 4:46 PM, "Michel 'ic' Luczak" <li...@benappy.com> wrote:

The ones I know do so on private VLANs (or ATM circuits on DSL) so anyway
unrelated to any client’s address space. Also, french triple play ISPs use
RFC1918 space for IPTV but again isolated of any customer network so
doesn’t really matter.

> On 2 Mar 2018, at 22:18, K. Scott Helms <kscotthe...@gmail.com> wrote:
>
> I won't comment on the sanity of doing so, but _many_ service providers
use
> EMTAs, ATAs, and other voice devices over RFC1918 space back to their
core.
>

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[K. Scott Helms]

I won't comment on the sanity of doing so, but _many_ service providers use
EMTAs, ATAs, and other voice devices over RFC1918 space back to their core.

On Fri, Mar 2, 2018 at 4:11 PM, Mark Andrews  wrote:

> Are you insane. ISPs should never use RFC 1918 addresses for stuff that
> talks to their customers.  They have no way of knowing which addresses the
> customers are using.
>
> Traffic from RFC 1918 addresses should be dropped by any sane border
> router which all routers connecting to a ISP are.
>
> --
> Mark Andrews
>
> > On 2 Mar 2018, at 22:49, Bjørn Mork  wrote:
> >
> > Owen DeLong  writes:
> >
> >> I don’t agree that making RFC-1918 limitations a default in any daemon
> makes any
> >> sense whatsoever.
> >
> > +1
> >
> > One of the more annoying anti-features I know of in this regard is the
> > dnsmasq rebind "protection".  It claims to protect web browsers on the
> > LAN against DNS rebind attacks.  But the implementation does not
> > consider which adresses are used on the LAN at all.  It simply blocks
> > any A record pointing to an RFC1918 address, making a few bogus
> > assumptions:
> > - IPv4 LAN addresses are selected from RFC1918
> > - RFC1918 addresses are never used on the WAN side of a CPE
> > - Noone use IPv6 on their LAN
> >
> > It's hard to know how many users have been bitten by the first
> > one. You'd have to depend on this rebind "protection" in the first
> > place, and that would be stupid.
> >
> > But the second assumption regularily bites end users when their ISP
> > provides some ISP internal service using RFC1918 addresses.  Which of
> course
> > is fine.
> >
> > The anti-feature has been enabled by default in OpenWrt for a long time,
> > ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that
> > there is a large user base having this enabled without knowing.
> >
> >> First, there are plenty of LANs out there that don’t use RFC-1918.
> >>
> >> Second, RFC-1918 doesn’t apply to IPv6 at all,
> >
> > Could you try to explain that to the OpenWrt guys?  Thanks
> >
> >
> >
> > Bjørn
>
>

Re: Opensource SNMP Trap Receivers ???

[K. Scott Helms]

Matthew,

Sadly, open source + SNMP traps != simple.

The simplest option that I've personally used in the past is SNMPTT with
Nagios.

https://paulgporter.net/2013/09/16/nagios-snmp-traps/

http://www.snmptt.org/docs/snmptt.shtml

The main problem is that SNMP traps, like most of SNMP, aren't simple
despite the name.  Having said that it can be done especially if the gear
doesn't change too often.

Scott Helms

On Tue, Feb 13, 2018 at 7:44 AM, Matthew Huff <mh...@ox.com> wrote:

> We are retiring a legacy SNMP system and are looking for a simple,
> opensource SNMP trap receiver/alerting system. We aren't looking for a full
> SNMP system, just something that will receive snmp traps and email/alert
> based on them.
>
> 1) Looking for something off the shelf, not a development project
> 2) Opensource or low cost
> 3) SNMP MIB compiler
>
> Any suggestions?
>
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
>
>
>

Re: Blockchain and Networking

[K. Scott Helms]

That sounds like giving up an awful lot of utility for a (at least in most
places) something that's an exceedingly rare corner case.  The other
problem is that even if the record is immutable there's nothing that
prevents governments from being coercive in other ways.  At the end of the
day there's no technology that prevents authoritarian governments from
behaving badly.

On Tue, Jan 23, 2018 at 6:27 PM, Jimmy Hess  wrote:

> On Tue, Jan 23, 2018 at 9:39 AM, John R. Levine  wrote:
>
> >
> > the problem isn't keeping the database, it's figuring out who can make
> > authoritative statements about each block of IP addresses.
>
> That is an inherently hierarchical question since all IP blocks originally
> > trace back to allocations from IANA.
> >
>
> Well;  It's a hierarchical question only because the current registration
> scheme is defined in
> a hierarchical manner.  If  BGP were being designed today,  we could
> choose  256-Bit  AS numbers,
> and allow  each mined or staked block to yield a block of AS numbers
> prepended by some
> random previously-unused 128-bit GUID.
>
> However,  a blockchain could also be used to allow an authority to make a
> statement representing
> a resource that can be made a non-withdrawable statement ---  in other
> words,  the authority's role
> or job in the registration process is to originate the registration,  and
> after that is done:
> their authoritative statement is accepted ONCE per resource.
>
> The registration is permanent ---  the authority has no ongoing role and no
> ability to later make
> a new conflicting statement about that same resource,   and   the
> authority  has  no operational role
> except to originate new registrations.
>
> This would mean that a foreign government could not coerce the authority
> to  "cancel"  or mangle
> a registration to meet a political or adversarial objective of disrupting
> the ability to co-ordinate networks,
> since the  number registry is an authority of  limited power:  not an
> authority of complete power.
>
>
> We can have arguments about the best way to document the chain of
> > ownership, and conspiracy theories about how the evil RIRs are planning
> to
> > steal our precious bodily flu^W^WIPs, but "put it in a blockchain!"
> > Puhleeze.
> > R's,
> > John
> >
>
> --
> -JH
>

Re: Broadcast television in an IP world

[K. Scott Helms]

Mike,

While that's true today it's changing rapidly.  Linear viewership is,
depending on your take on things, either in the beginning or the middle of
it's long tail phase.  You're right in that we'll have people using linear
viewing habits for a long time, but that model only looks sustainable over
the long term for either very large MSOs, the digital satellite operators,
and OTT offerings that offer a similar experience.  There's very little
investing in efficiencies for linear content as this point, other than how
it gets replaced.  Part of the change is technical, part generational
changes, and part overreach on the part of some of the content owners.

Scott Helms

On Tue, Nov 21, 2017 at 2:08 PM, Mike Hammett <na...@ics-il.net> wrote:

> I'm not doubting OTT is popular. There's just an awful lot of people that
> have zero interest (or ability) to use OTT. They will continue to consume
> entertainment linearly, regardless of the mechanism used to deliver it.
>
>
> People in NANOG often forget that most people aren't like us. Heck, most
> people in NANOG forget that not every network is like their network.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Baldur Norddahl" <baldur.nordd...@gmail.com>
> To: nanog@nanog.org
> Sent: Tuesday, November 21, 2017 12:46:43 PM
> Subject: Re: Broadcast television in an IP world
>
> I am not going to guess on a timeframe. I would like to point out that
> the youth ignore TV. They no longer have TVs on their rooms. It is all
> on smartphones or tablets these days. Even with the family in a living
> room, everyone might be sitting with their own device doing their own
> thing.
>
> We have a significant share of the customers that have no other TV than
> OTT streaming. Myself included. Here (Denmark) almost all TV channels
> are available as OTT streaming. The free national broadcast TV is also
> available for streaming (for free).
>
> With an Apple TV you can do all the same things that you can do with
> OTA, cable or satellite. Cheaper (*) and more convenient too. Far from
> everyone has discovered this yet, but since we cater to people that are
> cable cutters, a larger than usual share of our customers is doing
> exactly this.
>
> (*) I believe the OTT solutions are cheaper as long you do not want a
> lot of sport programming. If you do want sport I believe it is more
> expensive but you also have more options and content available.
>
> Regards,
>
> Baldur
>
>
> Den 21/11/2017 kl. 17.58 skrev Mike Hammett:
> > of the TV they use... through you. That doesn't count OTA, cable,
> satellite, etc.
> >
> > It won't change significantly any time soon. I know things are changing,
> but it'll still take five or ten years for those changes to significantly
> change traffic patterns.
> >
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions
> > http://www.ics-il.com
> >
> > Midwest-IX
> > http://www.midwest-ix.com
> >
> > - Original Message -
> >
> > From: "Baldur Norddahl" <baldur.nordd...@gmail.com>
> > To: nanog@nanog.org
> > Sent: Tuesday, November 21, 2017 10:52:09 AM
> > Subject: Re: Broadcast television in an IP world
> >
> > Den 21. nov. 2017 16.20 skrev "Mike Hammett" <na...@ics-il.net>:
> >
> > Unicasting what everyone watches live on a random evening would use
> > significantly more bandwidth than Game of Thrones or whatever OTT drop.
> > Magnitudes more. It wouldn't even be in the same ballpark.
> >
> >
> >
> > I agree as of this moment however that will change. Also note that our
> > customers do 100% of their TV as unicast OTT because that is the only
> thing
> > we offer. This does not cause nearly as much problems as you would
> expect.
> >
>
>
>

Re: Broadcast television in an IP world

[K. Scott Helms]

Luke,

I think I understand your example but the local broadcaster won't usually
(ever?) have the rights to retransmit the Super Bowl over IP.

Having said that, what you're describing is exactly what happens already
(without multicast) via multiple CDNs.  Multicast across the internet isn't
feasible (economically) today.  Multicast inside of an organization
certainly is and is very common.  Having said that, even popular content is
surprisingly sparse (when we look at flows) and even inside of edge
networks (DOCSIS, FTTH, xDSL, etc) it can be surprisingly challenging to
make the math work.  As soon as someone wants to pause the "big game" or
flips to another channel you now have to move their flow to unicast.  Even
when lots of people are watching the same event the economics aren't as
compelling as they might appear initially.


On Tue, Nov 21, 2017 at 9:29 AM, Luke Guillory <lguill...@reservetele.com>
wrote:

> The comment I was originally replying to was the following. I’ve said edge
> resources, nothing about WAN.
>
> The content provider (lets say local TV station that broadcasts the
>
> Superbowl) can just unicast to the ISP a single stream, and give the
>
> ISPs some pizza sized box (lets call it an "Appliance") and that box
>
> then provides unicast delivery to each customer watching the Superbowl.
>
>
>
>
>
> *Sent from my iPhone*
>
> On Nov 21, 2017, at 8:22 AM, K. Scott Helms <kscotthe...@gmail.com> wrote:
>
> It's not helpful for saving resources in DOCSIS (nor any other) edge
> networks.  The economics mean that, as bits get sold in the US and many
> other places, it won't be in the foreseeable future.  Customers care about
> popular video sources.  Popular content sources have CDNs with local nodes
> and/or direct (low cost) connections to their CDN.  That's far more
> efficient than allowing multicast across WAN links.
>
> K. Scott Helms
>
>
>
> Luke Guillory
> Vice President – Technology and Innovation
>
>
> <http://www.rtconline.com>
> Tel: 985.536.1212 <(985)%20536-1212>
> Fax: 985.536.0300 <(985)%20536-0300>
> Email: lguill...@reservetele.com
> Web: www.rtconline.com
> Reserve Telecommunications
> 100 RTC Dr
> <https://maps.google.com/?q=100+RTC+Dr+%0D+Reserve,+LA+70084=gmail=g>
> Reserve, LA 70084
>
>
>
>
>
>
> *Disclaimer:*
> The information transmitted, including attachments, is intended only for
> the person(s) or entity to which it is addressed and may contain
> confidential and/or privileged material which should not disseminate,
> distribute or be copied. Please notify Luke Guillory immediately by
> e-mail if you have received this e-mail by mistake and delete this e-mail
> from your system. E-mail transmission cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses. Luke Guillory therefore
> does not accept liability for any errors or omissions in the contents of
> this message, which arise as a result of e-mail transmission.
>
> On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory <lguill...@reservetele.com>
> wrote:
>
>> I’m not paying anything for local resources with regards to local edge
>> delivery, that’s capital expenditures not MRCs.
>>
>> Our edge networks aren’t unlimited or free, so while it’s not costing me
>> on the transit side there still are cost in terms of upgrades and so on.
>>
>> My point is that In some networks such as docsis conserving edge
>> resources can be helped with multicast.
>>
>>
>>
>> Sent from my iPhone
>>
>> On Nov 21, 2017, at 4:12 AM, Baldur Norddahl <baldur.nordd...@gmail.com
>> <mailto:baldur.nordd...@gmail.com>> wrote:
>>
>> Den 21. nov. 2017 00.42 skrev "Luke Guillory" <lguill...@reservetele.com
>> <mailto:lguill...@reservetele.com>>:
>>
>> Why would an ISP not want to conserve edge resources? If I’m doing iptv
>> I’m
>> better off doing multicast which would conserve loads of BW for something
>> popular like the Super Bowl. Especially if I’m doing this over docsis.
>>
>>
>>
>> You pay for 95th percentile. If that is decided by everyone watching Game
>> of Thrones one day, then using the same resources for Super Bowl the next
>> day will be for free.
>>
>>
>>
>>
>> Luke Guillory
>> Vice President – Technology and Innovation
>>
>>
>> [cid:imagef9b835.JPG@242ea556.429501f5] <http://www.rtconline.com
>> >
>>
>> Tel:985.536.1212
>> Fax:985.536.0300
>> Email:  lguill...@reservetele.c

Re: Broadcast television in an IP world

[K. Scott Helms]

It's not helpful for saving resources in DOCSIS (nor any other) edge
networks.  The economics mean that, as bits get sold in the US and many
other places, it won't be in the foreseeable future.  Customers care about
popular video sources.  Popular content sources have CDNs with local nodes
and/or direct (low cost) connections to their CDN.  That's far more
efficient than allowing multicast across WAN links.

K. Scott Helms

On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory <lguill...@reservetele.com>
wrote:

> I’m not paying anything for local resources with regards to local edge
> delivery, that’s capital expenditures not MRCs.
>
> Our edge networks aren’t unlimited or free, so while it’s not costing me
> on the transit side there still are cost in terms of upgrades and so on.
>
> My point is that In some networks such as docsis conserving edge resources
> can be helped with multicast.
>
>
>
> Sent from my iPhone
>
> On Nov 21, 2017, at 4:12 AM, Baldur Norddahl <baldur.nordd...@gmail.com<
> mailto:baldur.nordd...@gmail.com>> wrote:
>
> Den 21. nov. 2017 00.42 skrev "Luke Guillory" <lguill...@reservetele.com<
> mailto:lguill...@reservetele.com>>:
>
> Why would an ISP not want to conserve edge resources? If I’m doing iptv I’m
> better off doing multicast which would conserve loads of BW for something
> popular like the Super Bowl. Especially if I’m doing this over docsis.
>
>
>
> You pay for 95th percentile. If that is decided by everyone watching Game
> of Thrones one day, then using the same resources for Super Bowl the next
> day will be for free.
>
>
>
>
> Luke Guillory
> Vice President – Technology and Innovation
>
>
> [cid:imagef9b835.JPG@242ea556.429501f5] <http://www.rtconline.com>
>
> Tel:985.536.1212
> Fax:985.536.0300
> Email:  lguill...@reservetele.com
> Web:www.rtconline.com
>
> Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
>
>
>
>
>
> Disclaimer:
> The information transmitted, including attachments, is intended only for
> the person(s) or entity to which it is addressed and may contain
> confidential and/or privileged material which should not disseminate,
> distribute or be copied. Please notify Luke Guillory immediately by e-mail
> if you have received this e-mail by mistake and delete this e-mail from
> your system. E-mail transmission cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses. Luke Guillory therefore does
> not accept liability for any errors or omissions in the contents of this
> message, which arise as a result of e-mail transmission.
>
>

Re: Wireless (WiFi) MOS equivalent?

[Scott Helms]

Jim,

There isn't such an animal and that's because the notion of an opinion
score for voice is pretty easy to quantify, but a good WiFi experience
depends a lot more on what you find to be acceptable for your deployment
and that normally depends a lot on your budget.  What we do is determine
what our target metrics are and then measure to that, most of the
commercial APs and controllers can provide all this data, average speed,
clients per AP, average RSSI, number of associations and auths per minute,
and error counts.  The reason you can't just get an industry standardized
score is that while most conferences are happy if the average PHY speed is
over 6 mbps that's clearly bad in an enterprise service.


Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Wed, Mar 16, 2016 at 1:54 PM, Jim Wininger <jbot...@gmail.com> wrote:

> Hello all,
>
> Is there a WiFi equivalent to the VoIP MOS score?
>
> We are looking for a way to measure performance of a fairly large WiFi
> deployment.
>
> We have 8000+ access points (All Cisco). WE have the standard Cisco tools
> for managing the wireless network (ISE, Prime etc). But we are coming up
> short with a way to “score” the network.
>
> Does anyone have experience with this that might be able to help? How do
> large conferences “measure” wireless service quality etc? We are already
> doing end user surveys etc. We have “soft date”, we really need data points.
>
> —Jim

Re: CALEA Requirements

[Scott Helms]

Kevin,

That's largely true, but keep in mind that it's normal for people who have
had to fulfill a request to be disallowed from talking about it which makes
them seem even more rare than they actually are.  I'm also not familiar
with any laws that prevent state or local agencies from leveraging CALEA
and I've certainly seen it used on the voice side by state level law
enforcement.


Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Fri, Mar 18, 2016 at 4:19 PM, Kevin Burke <kbu...@burlingtontelecom.com>
wrote:

> Ignore it until you get the paperwork.  The local law enforcement can not
> get a warrant for the real time, full data capture.  Only FBI or other
> national agencies can get those subpeona's.  We went through this with our
> local police department.  They wanted to make sure we were prepared and
> wanted a test for the real time number capture on phone calls.  They didn't
> mention they don't have any equipment on their side to connect the T1.
>
> Ask your local neighbors.  Some area's have a number of local federal
> investigations.  If you get the deer in the headlights look from your
> competition then you may never get one of these.
>
> The full data captures are rare.
>
> Kevin Burke
> 802-540-0979
> Burlington Telecom - City of Burlington
> 200 Church St, Burlington, VT 05401
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Lorell Hathcock
> Sent: Monday, March 14, 2016 4:47 PM
> To: 'NANOG list' <nanog@nanog.org>
> Subject: CALEA Requirements
>
> NANOG:
>
>
>
> Can someone point me to the current CALEA requirements?
>
>
>
> As an ISP, should I be recording all internet traffic that passes my
> routers?  Or do I only have to record when and if I receive a court order?
>
>
>
> I'm not under any court order now, I just want to be sure that I am
> compliant going forward in my capabilities.
>
>
>
> Thanks!
>
>
>
> Lorell Hathcock
>
>

Re: Cable Operator List

[Scott Helms]

Colton,

Huawai has one, but I can't find the product page on their site off hand.
Here's one from Sumavision:

http://en.sumavision.com/product.asp?pageID=28=712

Harmonic's small form factor CMTS is remote PHY+MAC (at least the strand
mounted version is) but keep in mind that they've been primarily selling
those boxes (especially the indoor version) to MDU operators that don't
really have out side plant so they don't market it that way.

Casa is working with Teleste on remote PHY (I don't think it's got full
layer 2 in it).

Gainspeed also has a solution:

http://www.gainspeed.com/our-solution/gainspeeds-virtual-ccap-architecture/


Also, keep in mind that no one is going to be yelling about D3.1 until they
have the capability and none of the CCAPs do today.  As painful as it is
you're probably going to have to talk to some sales folks to get the most
up to date info.



Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Tue, Feb 9, 2016 at 3:20 PM, Colton Conor <colton.co...@gmail.com> wrote:

> Scott,
>
> Have any idea which exact vendors and model numbers are within this price
> range? So far I have just found mini CMTS systems like the Pico and
> Harmonic's. Both of these are a 16x4 configuration, but no mention of
> remote MAC+PHY nor DOSIS 3.1. Then their is Huawei's solution, but still I
> think that's more based on C-DOCSIS. Searching the vendors websites you
> recommended show no results for remote MAC+PHY in a small format.
>
> On Tue, Feb 2, 2016 at 2:44 PM, Scott Helms <khe...@zcorum.com> wrote:
>
>> Colton,
>>
>> D3.1 gear is just coming online right now.  If you're going to go with
>> the smaller PHY+MAC approach I'd just make sure the company has plans to
>> update their boxes to 3.1 in a decent (your judgement) amount of time.
>> Don't expect any 3.0 box to be software upgradeable to 3.1, the hardware is
>> quite different.  The PHY+MAC boxes are _generally_ < $10k and some are
>> talking about ~6k.
>>
>> All the vendors we've listed so far have plans for 3.1, but I don't have
>> a timeline for any of them.  Right now the market is still trying to decide
>> how modular CMTS will be rolled out, remote PHY, remote MAC+PHY, or a
>> combination.  For example, Cisco is (for the moment) betting that remote
>> PHY economics will be compelling for the larger operators, while Arris is
>> doing both approaches.
>>
>>
>> Scott Helms
>> Chief Technology Officer
>> ZCorum
>> (678) 507-5000
>> 
>> http://twitter.com/kscotthelms
>> 
>>
>> On Tue, Feb 2, 2016 at 3:31 PM, Colton Conor <colton.co...@gmail.com>
>> wrote:
>>
>>> Is a remote MAC+PHY the same thing as a Distributed Converged Cable
>>> Access Platform (D-CCAP) solution like Huawei is pushing? Is DOCSIS 3.1
>>> even out, or am I looking for something that does not exist yet?
>>>
>>> Are these remote MAC+PHY devices in the under 10K price range that
>>> these smaller all in one CMTS platforms are?
>>>
>>> On Tue, Feb 2, 2016 at 12:49 PM, Scott Helms <khe...@zcorum.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Feb 2, 2016 at 1:24 PM, Colton Conor <colton.co...@gmail.com>
>>>> wrote:
>>>>
>>>>> Yes, we are in the USA. So based on everyones recommendations, I am
>>>>> going to stay far away from EURODOCSIS. I was told be a vendor that
>>>>> Arris and other USA FCC certified cable modems could easily be flashed to
>>>>> EURODOCIS mode, so I did not think the CPE side was that big of a deal (is
>>>>> that even true). I was not aware that there were so many differences
>>>>> besides just the channel width.
>>>>>
>>>>
>>>> I wish this were the case, it would make my life easier.  The problem
>>>> is that there is a diplex filter that prevents the upstream burst from
>>>> being heard by the downstream receiver and for cost purposes all the D3 and
>>>> earlier modems have fixed filters.  What that means is that a EuroDOCSIS
>>>> modem can (sometimes) be flashed to use 6MHz channels, but the reverse is
>>>> NOT true.  In any case we don't recommend using Euro modems that are
>>>> flashed to US standards in production (nor do the vendors) because you'll
>>>> see much more upstream leakage.
>>>>
>>>>
>>>>>
>>>>> So, assuming we are

Re: Cable Operator List

[Scott Helms]

Colton,

Arris has plans to release a remote PHY+MAC box but I don't think they have
released anything but their plans.  John Chapman said last year at SCTE
that Cisco was going down the remote PHY only path because they think that
will be the most cost effective way for large MSOs to deploy MHAv2.


Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Tue, Feb 9, 2016 at 7:48 PM, Colton Conor <colton.co...@gmail.com> wrote:

> Scott,
>
> I was able to find the Huawie solution:
> http://www.huawei.com/ucmf/groups/public/documents/webasset/hw_415387.pdf
> Looks like its 32x4 capable today, and software upgradeable to DOCSIS 3.1
> which is nice. Appears to also have a 10G uplink port on it. Seems like the
> best solution tech spec wise I have seen so far. And probably cheap too!
>
> The Sumavision one you linked to seems to be a 16X4 version, but future
> improved to 32 channels DS and 10 channels US. Future improved to DOCSIS
> 3.1 Not sure if that means the hardware is already capable and just a
> software upgrade or what.
>
> I assume the Harmonic box you are mentioning is the is the NSG Exo:
> http://harmonicinc.com/product/cable-edge/nsg-exo  According to specs its
> only a 16x4 unit today. I don't think you can upgrade to greater than 16x4
> since there is only a gig-e uplink. I see no mention of DOCSIS 3.1. The
> stand (outdoor version) seems to be the same as the indoor.
>
> The indoor version of the NSG EXO spec wise looks identical to the PICO
> Digital miniCMTS200a. According to Daniel Corbe these two units use the
> same chipset (along with the Blonder Tongue CMTS:
> http://www.blondertongue.com/shop-by-department/catv/ip-over-coax/docsis/euro-docsis/)
> Based on pricing I have seen so far, the Pico is the cheapest. Harmonic is
> a little more, and Blonder Tongue is a bit more than Harmonic. Out of these
> three I would assume Harmonic is the most reputable?
>
> I have not heard anything back from gainspeed. Based on the info on their
> website, I am not positive they have an actual product released yet.
>
> Not mentioned so far are Arris and Cisco. Any idea if either of these
> vendors has a small and low cost model?
>

Re: Cable Operator List

[Scott Helms]

On Tue, Feb 2, 2016 at 1:24 PM, Colton Conor <colton.co...@gmail.com> wrote:

> Yes, we are in the USA. So based on everyones recommendations, I am going
> to stay far away from EURODOCSIS. I was told be a vendor that Arris and
> other USA FCC certified cable modems could easily be flashed to EURODOCIS
> mode, so I did not think the CPE side was that big of a deal (is that even
> true). I was not aware that there were so many differences besides just the
> channel width.
>

I wish this were the case, it would make my life easier.  The problem is
that there is a diplex filter that prevents the upstream burst from being
heard by the downstream receiver and for cost purposes all the D3 and
earlier modems have fixed filters.  What that means is that a EuroDOCSIS
modem can (sometimes) be flashed to use 6MHz channels, but the reverse is
NOT true.  In any case we don't recommend using Euro modems that are
flashed to US standards in production (nor do the vendors) because you'll
see much more upstream leakage.


>
> So, assuming we are talking about DOCSIS only (and not EURODOCSIS), what
> do you recommend? I like the idea of being able to upgrade to 3.1, but not
> sure if there are any small systems capable of this? By small I mean
> something that could feed less than 100 units, and be economical to do.
> Cable has the advantage of cheap modems, so it's really the CMTS side.
>

In that case I'd definitely go with a remote MAC+PHY.  That's the only way
you're going to get a good price point and decent performance unless you
want to use the secondary market, which actually isn't a bad idea right
now.  A used 7225 with 8x8 blades is pretty cheap, but it's centralized
CMTS that would cover ~3k subs.

>
> Please remember I am only interested in data internet services over this
> plant. Something that works for garden style layouts where I can bring
> fiber or coaxial to the side of a garden townhome that has between 4 to 16
> units inside of it. The reason I requested a harden outdoor unit is that
> most all of the garden style properties have both the phone
> and coaxial drops on the outside of the building. There is no central
> closet or room. Plus we are in the south, so hardened for the
> heat exposure makes sense.
>
> A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like what
> I want. I will check into Huawei and Gainspeed. Who else makes these?
>

In no particular order, Arris is or will be, Teleste (Euro vendor trying to
break into the US),  Sumavision, Altera, and ton more I can't remember.
Come to one of the SCTE shows (it's in Philadelphia this year) if you want
to be deluged with them :)

>
>
>
>
>
> On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms <khe...@zcorum.com> wrote:
>
>> Nick,
>>
>> Absolutely, if your plant is in Europe or one of the other areas (lots of
>> Africa and the middle East is like that) that adopted EuroDOCSIS I'd agree
>> wholeheartedly.  I didn't see Colton say where they're located, but all
>> North America is the US flavor so that's what I assume on NANOG.
>>
>> That being said, the best thing that seldom gets mentioned about D3.1 is
>> getting us to unified channelization.
>> Scott Helms wrote:
>> > That very small upside for an extreme downside.Trying to hire someone
>> > to work on your system with Euro channelization, not to mention buying
>> > amplifiers and passives is a huge PITA.
>>
>> ... if your plant is in the US.
>>
>> > I have customers in Europe who
>> > decided to do US DOCSIS and they universally wish they had used the
>> > local "flavor".
>>
>> as you say, eurodocsis works well in europe.
>>
>> 3.1 will be a major improvement when it materialises.
>>
>> Nick
>>
>
>

Re: Cable Operator List

[Scott Helms]

Colton,

D3.1 gear is just coming online right now.  If you're going to go with the
smaller PHY+MAC approach I'd just make sure the company has plans to update
their boxes to 3.1 in a decent (your judgement) amount of time.  Don't
expect any 3.0 box to be software upgradeable to 3.1, the hardware is quite
different.  The PHY+MAC boxes are _generally_ < $10k and some are talking
about ~6k.

All the vendors we've listed so far have plans for 3.1, but I don't have a
timeline for any of them.  Right now the market is still trying to decide
how modular CMTS will be rolled out, remote PHY, remote MAC+PHY, or a
combination.  For example, Cisco is (for the moment) betting that remote
PHY economics will be compelling for the larger operators, while Arris is
doing both approaches.


Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Tue, Feb 2, 2016 at 3:31 PM, Colton Conor <colton.co...@gmail.com> wrote:

> Is a remote MAC+PHY the same thing as a Distributed Converged Cable
> Access Platform (D-CCAP) solution like Huawei is pushing? Is DOCSIS 3.1
> even out, or am I looking for something that does not exist yet?
>
> Are these remote MAC+PHY devices in the under 10K price range that these
> smaller all in one CMTS platforms are?
>
> On Tue, Feb 2, 2016 at 12:49 PM, Scott Helms <khe...@zcorum.com> wrote:
>
>>
>>
>>
>>
>> On Tue, Feb 2, 2016 at 1:24 PM, Colton Conor <colton.co...@gmail.com>
>> wrote:
>>
>>> Yes, we are in the USA. So based on everyones recommendations, I am
>>> going to stay far away from EURODOCSIS. I was told be a vendor that
>>> Arris and other USA FCC certified cable modems could easily be flashed to
>>> EURODOCIS mode, so I did not think the CPE side was that big of a deal (is
>>> that even true). I was not aware that there were so many differences
>>> besides just the channel width.
>>>
>>
>> I wish this were the case, it would make my life easier.  The problem is
>> that there is a diplex filter that prevents the upstream burst from being
>> heard by the downstream receiver and for cost purposes all the D3 and
>> earlier modems have fixed filters.  What that means is that a EuroDOCSIS
>> modem can (sometimes) be flashed to use 6MHz channels, but the reverse is
>> NOT true.  In any case we don't recommend using Euro modems that are
>> flashed to US standards in production (nor do the vendors) because you'll
>> see much more upstream leakage.
>>
>>
>>>
>>> So, assuming we are talking about DOCSIS only (and not EURODOCSIS), what
>>> do you recommend? I like the idea of being able to upgrade to 3.1, but not
>>> sure if there are any small systems capable of this? By small I mean
>>> something that could feed less than 100 units, and be economical to do.
>>> Cable has the advantage of cheap modems, so it's really the CMTS side.
>>>
>>
>> In that case I'd definitely go with a remote MAC+PHY.  That's the only
>> way you're going to get a good price point and decent performance unless
>> you want to use the secondary market, which actually isn't a bad idea right
>> now.  A used 7225 with 8x8 blades is pretty cheap, but it's centralized
>> CMTS that would cover ~3k subs.
>>
>>>
>>> Please remember I am only interested in data internet services over this
>>> plant. Something that works for garden style layouts where I can bring
>>> fiber or coaxial to the side of a garden townhome that has between 4 to 16
>>> units inside of it. The reason I requested a harden outdoor unit is that
>>> most all of the garden style properties have both the phone
>>> and coaxial drops on the outside of the building. There is no central
>>> closet or room. Plus we are in the south, so hardened for the
>>> heat exposure makes sense.
>>>
>>> A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like
>>> what I want. I will check into Huawei and Gainspeed. Who else makes these?
>>>
>>
>> In no particular order, Arris is or will be, Teleste (Euro vendor trying
>> to break into the US),  Sumavision, Altera, and ton more I can't remember.
>> Come to one of the SCTE shows (it's in Philadelphia this year) if you want
>> to be deluged with them :)
>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms <khe...@zcorum.com> wrote:
>>>
>>>> Nick,
>>>>
>>>> Absolutely, if your plant is in Europe or one of the other areas (lot

Re: Cable Operator List

[Scott Helms]

Colton,

You're only going to find very small, old, or not certified (usually still
very small) CMTSs that only do layer 2.  All of the major vendors are doing
layer 3 because we've found out over time that not doing it is more
problematic.  Having said that, if you're looking for a more ONT/DSLAM type
of install there is a new type of CMTSs that look at lot like traditional
telco DLC/BLC deployments.

https://intx15.ncta.com/wp-content/uploads/2015/05/17-Remote-PHY.pdf

The remote PHY+MAC boxes are basically mini-CMTSs and they typically rely
on something upstream handling layer 3.  The remote PHY boxes are different
as they don't even do a complete layer 2 and instead forward DOCSIS frames
back to a centralized CMTS/CCAP.



Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Tue, Feb 2, 2016 at 10:43 AM, Colton Conor <colton.co...@gmail.com>
wrote:

> Graham,
>
> What is DSG? Yes, I am really looking for a CMTS to perform layer 2 just as
> our DSLAMs and GPON do today. All layer 3 will be upstream. I would want to
> handle DHCP upstream, but have the CMTS insert Option 82 if that is a
> feature. Not sure what specific CMTS stuff you need.
>
> On Tue, Feb 2, 2016 at 8:12 AM, Graham Johnston <johnst...@westmancom.com>
> wrote:
>
> > Colton,
> >
> > It really depends on what features you are after.  I've demo'd one of the
> > small 1/2RU C-DOCSIS CMTSs, and they certainly work.  For us though it
> was
> > a non-starter as we needed support for DSG and it didn't have it.  If all
> > you are after is basic internet connectivity there is Pico Digital,
> Vecima,
> > Sumavision, as well as others.  Many of the C-DOCSIS CMTSs seem either
> only
> > support, or are more often meant to support layer 2 operations where the
> > routing happens upstream from the CMTS.
> >
> > Graham Johnston
> > Network Planner
> > Westman Communications Group
> > 204.717.2829
> > johnst...@westmancom.com
> > think green; don't print this email.
> >
> >
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Colton Conor
> > Sent: Tuesday, February 02, 2016 8:00 AM
> > To: Daniel Corbe
> > Cc: NANOG
> > Subject: Re: Cable Operator List
> >
> > Well, maybe NANOG's not a bad place for this post then! I would like to
> > know more about the data-only side of CMTS systems, and who the main
> > vendors are.
> >
> > We have MDU properties where there is either old inside CAT3 phone wire,
> or
> > coaxial cable. We have looked and are very familiar with the multiple
> > technologies that work over phone lines namely VDSL2 and G.FAST. However,
> > using the coaxial cable seems to be a much better solution than using the
> > phone wires.
> >
> > So I am looking for compacts, low cost CMTS systems. Based on the specs,
> I
> > am looking for something at least DOCSIS 3.0 capable, with at least 16X4
> > output. Something with the ability to upgrade to software upgrade to
> DOCSIS
> > 3.1 would be nice, but I doubt that would be a low cost solution.
> >
> > Whats out there for small operators that don't want a large chassis based
> > system to feed an entire town with.
> >
> > So far I have found the
> > http://picodigital.com/product-details.php?ID=miniCMTS200a which seems
> to
> > retail for under $5000.
> >
> >
> > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe <dco...@hammerfiber.com>
> > wrote:
> >
> > >
> > > > On Feb 2, 2016, at 8:42 AM, Colton Conor <colton.co...@gmail.com>
> > wrote:
> > > >
> > > > Are there any mailing lists out there dedicated for cable/MSO type
> > > > operators?
> > > >
> > >
> > > I'm curious about this too.
> > >
> > > I’m not a cable operator (in that I haven’t successfully registered
> for a
> > > cable franchise yet) but I do operate a docsis network and I’ve
> > > successfully negotiated the treacherous waters of obtaining and
> providing
> > > content to my users.
> > >
> > > I’m still a bit green behind the ears but I could probably offer some
> > > measure of assistance if you have a specific question.
> > >
> > > -Daniel
> > >
> > >
> >
>

Re: Cable Operator List

[Scott Helms]

The biggest reason to not do EuroDOCSIS is logistics and dealing with
various TAC organizations versus a pretty small increase in per channel
performance (but not per hertz).  I'd pretty strongly recommend against it,
just because you're going to run into issues ranging from buying modems, to
dealing with node vendors, to finding people who can do basic stuff like
plant balancing.  You wouldn't think it would matter, but it throws people
off to see that extra channel bandwidth.

My 2 cents, buy CMTS/CCAP gear that's upgradeable to D3.1, ie CBR8, E6000,
or the big Casa unit, for the time being shoot for 24 channel downstream
bonding groups (24 * ~37mbps - overhead) which yields about 740 mbps
usable.  That's plenty for most nodes, especially since you're not offering
video you can have many bonding groups since channel space isn't a problem.


Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Tue, Feb 2, 2016 at 10:47 AM, Colton Conor <colton.co...@gmail.com>
wrote:

> Daniel,
>
> Thanks for the wealth of information. What kind of speeds are you offering?
> How many customers are you putting on one of these boxes? What modems are
> you using?
>
> I would honestly perfer something that was hardened for outdoor use. Think
> garden style apartments. What is the best for something like that?
>
> Comparing DOCIS 3 to VDSL2, the modems and CMTS appear to be more cost
> effective per customer. G.FAST I have  not seen pricing on, but I expect it
> to be more than VDSL2.
>
> Any reasons not to use EURO DOCSIS in the USA? Looks like it offers more
> speeds by using fatter channels. We don't plan on offering TV, but even if
> we did couldn't we just start the channels at a higher range, and still use
> EURO DOCSIS?
>
> On Tue, Feb 2, 2016 at 8:17 AM, Daniel Corbe <dco...@hammerfiber.com>
> wrote:
>
> > Hey Colton,
> >
> > We’re using small 16 channel CMTS systems for residential MDUs and
> > colocating them directly on premise inside of wiring closets and then
> > connecting them by metro ethernet.  We’ve had great successes so far with
> > this model.
> >
> > There’s lots of CMTS vendors.
> >
> > There’s tons of used Motorola BSR 64Ks on the market, but be aware of the
> > lack of useful IPv6 features (like prefix delegation) in older software
> > releases.  If you buy a box and want to run 7.x or 8.x, you’ll need to
> > relicense your downstream and upstream channels at some additional
> > arbitrary fixed cost.
> >
> > I’m personally fond of these things:
> >
> > http://picodigital.com/product-details.php?ID=miniCMTS200a
> >
> > You can only bond 16 channels together max though because that’s all the
> > box supports and you can’t bond across boxes; however, these things are
> > less than 4 grand if you buy them in bulk so they’re really fucking easy
> to
> > just spam everywhere.
> >
> > Blonder Tongue makes a pizza-box style CMTS too:
> >
> >
> >
> http://www.blondertongue.com/shop-by-department/catv/ip-over-coax/docsis/euro-docsis/
> >
> > As does Harmonics:
> >
> > http://harmonicinc.com/product/cable-edge/nsg-exo
> >
> > All three are based on the same chipset, so the real differentiation is
> > price and firmware features.
> >
> > Then there’s Cisco.
> >
> > The UBR is a popular platform.  And pretty soon there’s going to be a
> glut
> > of UBR10Ks on the Market because Comcast is busy ripping their UBRs out
> of
> > production because they’re upgrading their cable plant to the CBR
> platform.
> >
> > Then the Arris C4, if you have deep pockets, is a modern version of the
> > BSR:
> >
> > http://www.arris.com/products/c4-cmts/
> >
> >
> > > On Feb 2, 2016, at 9:00 AM, Colton Conor <colton.co...@gmail.com>
> wrote:
> > >
> > > Well, maybe NANOG's not a bad place for this post then! I would like to
> > know more about the data-only side of CMTS systems, and who the main
> > vendors are.
> > >
> > > We have MDU properties where there is either old inside CAT3 phone
> wire,
> > or coaxial cable. We have looked and are very familiar with the multiple
> > technologies that work over phone lines namely VDSL2 and G.FAST. However,
> > using the coaxial cable seems to be a much better solution than using the
> > phone wires.
> > >
> > > So I am looking for compacts, low cost CMTS systems. Based on the
> specs,
> > I am looking for something at least DOCSIS 3.0 capable, with at least
> 16X4
> > output. 

Re: Cable Operator List

[Scott Helms]

Nick,

Absolutely, if your plant is in Europe or one of the other areas (lots of
Africa and the middle East is like that) that adopted EuroDOCSIS I'd agree
wholeheartedly.  I didn't see Colton say where they're located, but all
North America is the US flavor so that's what I assume on NANOG.

That being said, the best thing that seldom gets mentioned about D3.1 is
getting us to unified channelization.
Scott Helms wrote:
> That very small upside for an extreme downside.Trying to hire someone
> to work on your system with Euro channelization, not to mention buying
> amplifiers and passives is a huge PITA.

... if your plant is in the US.

> I have customers in Europe who
> decided to do US DOCSIS and they universally wish they had used the
> local "flavor".

as you say, eurodocsis works well in europe.

3.1 will be a major improvement when it materialises.

Nick

Re: Cable Operator List

[Scott Helms]

Nick,

That very small upside for an extreme downside.  Trying to hire someone to
work on your system with Euro channelization, not to mention buying
amplifiers and passives is a huge PITA.  I have customers in Europe who
decided to do US DOCSIS and they universally wish they had used the local
"flavor".


Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Tue, Feb 2, 2016 at 11:12 AM, Nick Hilliard <n...@foobar.org> wrote:

> Scott Helms wrote:
> > My 2 cents, buy CMTS/CCAP gear that's upgradeable to D3.1, ie CBR8,
> E6000,
> > or the big Casa unit, for the time being shoot for 24 channel downstream
> > bonding groups (24 * ~37mbps - overhead) which yields about 740 mbps
> > usable.
>
> the good thing about eurodocsis is that it gives you a full 1gig usable
> if you're bonding over 24 channels.  There's a natural residential
> performance plateau at 1G because 10G NICs haven't really made it to the
> consumer level yet, which means that if you want to hand off > 1gbit,
> things become more expensive and/or more complicated.
>
> Nick
>

Re: Binge On! - get your umbrellas out, stuff's hitting the fan.

[Scott Helms]

Comcast uses a standardized protocol called IPDR for their accounting and
if they're still using the same software collector that they were a few
years ago it was independently verified for accuracy.  IPDR had been part
of the DOCSIS protocol for nearly a decade and is publicly documented.

Now, what (if anything) they choose to zero rate or otherwise manipulate I
can't  speak on, but the collection of the usage is well understood,
independent of the CPE, and extremely accurate.
On Jan 9, 2016 12:05 PM, "Robert Webb"  wrote:

> Unfortunately when it comes to "competition" in the wireless world, even
> though there are multiple providers, the consumer will always be gouged
> given the attitude of today's providers to just follow what the other does.
> In my opinion, kind of a in the public eye form of collusion. So there will
> never be a true competition based market in the wireless given the current
> players.
>
> There should be certifications for measurement is that is what my bill is
> going to be based on as a consumer. My power meter, gas meter, water meter,
> etc. get replaced every so often for calibration and the particular utility
> will come out and swap or test on site if I think there is an issue.
>
> Unfortunately, providers like Comcast, yes, I know they aren't wireless,
> but their usage meter is a joke and a proprietary based joke at that. I do
> not think I have ever seen anyone from Comcast willing to describe exactly
> how their meter works and what is and is not counted towards usage. I am
> not a wireless expert, but my guess is that it would be even more difficult
> to accurately track usage on wireless given the portable nature.
>
> (In my area, luckily, my landline ISP doesn't charge or have caps either.
> But my wireless carrier has caps. And given the data hungry phones these
> days in which a lot of the data cannot be controlled by the user, then I
> certainly want the technical details of the usage calculation open to me
> for review.)
>
> Robert Webb
>
> On Sat, 9 Jan 2016 10:46:29 -0600 (CST)
>  Mike Hammett  wrote:
>
>> The cost to the provider is irrelevant to the consumer. Cost to the
>> consumer is all the consumer should be concerned with. Competition,
>> industry and media would serve as the barometer to sensible or ridiculous
>> pricing.
>> There are a myriad of ways to measure usage. I'm not sure there are any
>> certifications for any other billing relating to the Internet, so why start
>> now?
>>
>> (My ISP doesn't charge for usage and I don't intend to until the industry
>> makes that shift. I'm just debating this side.)
>>
>> - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
>>
>> Midwest Internet Exchange http://www.midwest-ix.com
>>
>> - Original Message -
>>
>> From: "Robert Webb"  To: "Mike Hammett" <
>> na...@ics-il.net> Cc: "North American Network Operators' Group" <
>> nanog@nanog.org> Sent: Saturday, January 9, 2016 10:37:23 AM Subject:
>> Re: Binge On! - get your umbrellas out, stuff's hitting the fan.
>> The normal consumer has no way to correlate what the "real" cost is as
>> the providers keep their "costs" for bandwidth, transit, etc. proprietary
>> secrets and always lie to the consumer and muddy the picture of what the
>> ISP actually pays for regarding bits!
>> Additionally, until there can be proper tools that are "certified" for
>> measuring usage, then usage based billing will never be viable.
>> Robert Webb
>> On Sat, 9 Jan 2016 10:11:29 -0600 (CST) Mike Hammett 
>> wrote:
>>
>>> My point on usage based billing isn't meant to stifle anything, but to
>>> provide equitable service to everyone at a fair price. $10/gig certainly
>>> isn't a fair price for almost any network. People pay variable rates for
>>> water, electricity, gas, food, etc., etc.
>>> Is it necessarily a bad thing if people stop to think about what their
>>> usage costs?
>>>
>>> - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
>>>
>>
>>
>>
>
>

RE: Favorite GPON Vendor?

[Scott Helms]

Frank,

Take a look at this webinar.

https://www.webcaster4.com/Webcast/Page?companyId=116=10264
On Nov 12, 2015 7:03 PM, "Frank Bulk"  wrote:

> What does ADTRAN's NG-PON2 upgrade path have over Calix's?
>
> Frank
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Josh Reynolds
> Sent: Wednesday, November 11, 2015 8:49 PM
> To: NANOG 
> Subject: Re: Favorite GPON Vendor?
>
> We are about do deploy Calix, but after hearing about $company
> deploying Adtran and liking their chassis features and NG-PON2 upgrade
> path, we are now open to other vendors. Price IS a concern for us, but
> not THE concern.
>
> This may sound "wacky" to some, but if anybody on here is using Huawei
> GPON gear, could you contact me off list? Thanks
> (josh AT kyneticwifi.com)
>
> On Mon, Nov 9, 2015 at 8:49 AM, Jay Patel  wrote:
> > Who is your favorite GPON  OLT/ONU Vendor? Why?   I am looking for
> > recommendations
> >
> > I apologize in advance , if you feel my question is inappropriate for
> this
> > mailing list ( feel free to point me to right forum/mailing list).
> >
> > Regards,
> > Jay.
>
>
>

Re: SNMP - monitoring large number of devices

[Scott Helms]

Pavel,

AFAIK there are no frameworks that solve, or even come close to solving,
this problem.  The first thing to learn is how to do asynchronous SNMP
calls that will let you send out requests without having to wait for the
response.  How you do those will vary by the language that you're using.
Next, figure out to scale the processing and persisting of the returns and
try and learn (without causing an impact) how many simultaneous SNMP
requests your CMTSs will deal with while at the same time handling their
normal load from customer traffic.  BULKGETS are very handy, but they will
also cause problems because some platforms limit the max size of the SNMP
return.

>From my experience building your server side programming to do 50,000
modems in <5 minutes is very doable, but unless your dealing with more than
10 CMTSs you probably can't do it in production without impacting
performance.  Cisco 10Ks still have absolute caps on the amount of SNMP
they will allow and other manufacturers and models do different things that
limit what you can do.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Tue, Sep 29, 2015 at 4:20 PM, Pavel Dimow <paveldi...@gmail.com> wrote:

> Hi all,
>
> recently I have been tasked with a NMS project. The idea is to pool about
> 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a
> one million OID's). Before you say check out some very professional and
> expensive solutions I would like to know are there any alternatives like
> open source "snmp framework"? To be more descriptive many of you knows how
> big is the mess with snmp on cable modem. You always first perform snmp
> walk in order to discover interfaces and then read the values for those
> interfaces. As cable modem can bundle more DS channels, one time you can
> have one and other time you can have N+1 DS channels = interfaces. All in
> all I don't believe that there is something perfect out there when it comes
> to tracking huge number of cable modems so I would like to know is there
> any "snmp framework" that can be exteded and how did you (or would you)
> solve this problem.
>
> Thank you.
>

Re: cisco.com unavailable

[Scott Helms]

I get there with no problem.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Mon, Sep 21, 2015 at 2:51 PM, Murat Kaipov <mkai...@outlook.com> wrote:

> Hi folks!
> Is cisco.com <http://cisco.com/> unavailable or it is affected just for
> Rostelecom?

Re: WiFI on utility poles

[Scott Helms]

This sounds like a hypothetical complaint, AFAIK none of the members of the
CableWiFi consortium are deploying APs outside of their footprint.  Since
most of the APs use a cable modem for their backhaul it's not really
feasible to be without at least one broadband option (the cable MSO) and be
impaired by the CableWiFi APs.

Now, there is one potential exception to this I'm aware of which is
Comcast's Xfinity on Campus service, but I'd expect the number of colleges
they're servicing that aren't already getting cable broadband service to
approach zero.

http://www.philly.com/philly/business/20150909_Comcast_streams_onto_college_campuses.html

https://xfinityoncampus.com/login


Having said all of that, I'd agree that a good radio resource management
approach would benefit all of us, including the CableWiFi guys.

http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch <ja...@puck.nether.net> wrote:

>
> > On Sep 10, 2015, at 9:00 AM, Mike Hammett <na...@ics-il.net> wrote:
> >
> > 5 GHz noise levels affecting people whose primary means of Internet
> access is via fixed wireless .
> >
>
> This is a huge deal for those people like myself that depend on fixed
> wireless for access at home because there is no broadband available despite
> incentives given by cities and states and the federal government.
>
> The local WISPs are good at coordinating access in these ISM bands amongst
> themselves but when someone appears with a SSID without doing a peek at the
> spectrum (note: not a site survey, but actual spectrum view w/ waterfall,
> as site survey only checks for the channel width that the client radio is
> configured for, not al the 10, 15, 8, 30mhz wide variants).
>
> It’s just poor practice to show up and break something else because you
> can’t be bothered to notice the interference or noise floor you created.  I
> suspect the hardware that Comcast is using doesn’t notice this interference
> or adjacent channel issues.  With the FCC aiming to let cell carriers also
> clog the 5ghz ISM band it’s only going to get worse.
>
> - Jared

Re: WiFI on utility poles

[Scott Helms]

OPM, as in Other People's Money?  If that's what you meant I don't think
that's an accurate description since AFAIK Comcast didn't get any CAF money.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Thu, Sep 10, 2015 at 11:46 AM, Mike Hammett <na...@ics-il.net> wrote:

> I wish IEEE would natively support smaller channels as that's what's
> needed most of the time. Interference would be so much less.
>
> If there's opportunity for Comcast to work with the WISP community on
> channel selection to avoid mutual destruction, then great.
>
> That said, the cable company's efforts scream of OPM.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
> - Original Message -
>
> From: "Jared Mauch" <ja...@puck.nether.net>
> To: "Mike Hammett" <na...@ics-il.net>
> Cc: "Jason Livingood" <jason_living...@cable.comcast.com>, "Corey
> Petrulich" <corey_petrul...@cable.comcast.com>, "Kenneth Falkenstein" <
> ken_falkenst...@cable.comcast.com>, "NANOG mailing list" <nanog@nanog.org>
> Sent: Thursday, September 10, 2015 9:52:59 AM
> Subject: Re: WiFI on utility poles
>
>
> > On Sep 10, 2015, at 9:00 AM, Mike Hammett <na...@ics-il.net> wrote:
> >
> > 5 GHz noise levels affecting people whose primary means of Internet
> access is via fixed wireless .
> >
>
> This is a huge deal for those people like myself that depend on fixed
> wireless for access at home because there is no broadband available despite
> incentives given by cities and states and the federal government.
>
> The local WISPs are good at coordinating access in these ISM bands amongst
> themselves but when someone appears with a SSID without doing a peek at the
> spectrum (note: not a site survey, but actual spectrum view w/ waterfall,
> as site survey only checks for the channel width that the client radio is
> configured for, not al the 10, 15, 8, 30mhz wide variants).
>
> It’s just poor practice to show up and break something else because you
> can’t be bothered to notice the interference or noise floor you created. I
> suspect the hardware that Comcast is using doesn’t notice this interference
> or adjacent channel issues. With the FCC aiming to let cell carriers also
> clog the 5ghz ISM band it’s only going to get worse.
>
> - Jared
>

Re: WiFI on utility poles

[Scott Helms]

We should all be complaining, vociferously, about LTE-U.  I've seen the
tests and as it exists today LTE-U completely creams WiFi and is only
usable by someone who owns a LTE license.  WiFi APs will cohabitate fairly
well, even if they share the same channel, because WiFi is a listen before
transmitting protocol.  LTE and LTE-U is a centrally scheduled protocol and
doesn't have a back off mechanism.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Thu, Sep 10, 2015 at 12:03 PM, Yury Shefer <she...@gmail.com> wrote:

> And the same guys (NCTA) complain about LTE-U - how dangerous it is for
> their s/business/WiFi
>
>
> http://arstechnica.com/information-technology/2015/08/verizon-and-t-mobile-join-forces-in-fight-for-wi-fi-airwaves/
>
>
>
> On Thu, Sep 10, 2015 at 8:00 AM, Scott Helms <khe...@zcorum.com> wrote:
>
>> This sounds like a hypothetical complaint, AFAIK none of the members of
>> the
>> CableWiFi consortium are deploying APs outside of their footprint.  Since
>> most of the APs use a cable modem for their backhaul it's not really
>> feasible to be without at least one broadband option (the cable MSO) and
>> be
>> impaired by the CableWiFi APs.
>>
>> Now, there is one potential exception to this I'm aware of which is
>> Comcast's Xfinity on Campus service, but I'd expect the number of colleges
>> they're servicing that aren't already getting cable broadband service to
>> approach zero.
>>
>>
>> http://www.philly.com/philly/business/20150909_Comcast_streams_onto_college_campuses.html
>>
>> https://xfinityoncampus.com/login
>>
>>
>> Having said all of that, I'd agree that a good radio resource management
>> approach would benefit all of us, including the CableWiFi guys.
>>
>> http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/
>>
>>
>> Scott Helms
>> Vice President of Technology
>> ZCorum
>> (678) 507-5000
>> 
>> http://twitter.com/kscotthelms
>> 
>>
>> On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch <ja...@puck.nether.net>
>> wrote:
>>
>> >
>> > > On Sep 10, 2015, at 9:00 AM, Mike Hammett <na...@ics-il.net> wrote:
>> > >
>> > > 5 GHz noise levels affecting people whose primary means of Internet
>> > access is via fixed wireless .
>> > >
>> >
>> > This is a huge deal for those people like myself that depend on fixed
>> > wireless for access at home because there is no broadband available
>> despite
>> > incentives given by cities and states and the federal government.
>> >
>> > The local WISPs are good at coordinating access in these ISM bands
>> amongst
>> > themselves but when someone appears with a SSID without doing a peek at
>> the
>> > spectrum (note: not a site survey, but actual spectrum view w/
>> waterfall,
>> > as site survey only checks for the channel width that the client radio
>> is
>> > configured for, not al the 10, 15, 8, 30mhz wide variants).
>> >
>> > It’s just poor practice to show up and break something else because you
>> > can’t be bothered to notice the interference or noise floor you
>> created.  I
>> > suspect the hardware that Comcast is using doesn’t notice this
>> interference
>> > or adjacent channel issues.  With the FCC aiming to let cell carriers
>> also
>> > clog the 5ghz ISM band it’s only going to get worse.
>> >
>> > - Jared
>>
>
>
>
> --
> Best regards,
> Yury.
>

Re: Google Apps for ISPs -- Lingering fallout

[Scott Helms]

Ryan,

Most certainly, the charges varied some  because of size and other factors
but it was around 25 cents monthly per Gmail box.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Mon, Aug 24, 2015 at 1:43 AM, Ryan Finnesey r...@finnesey.com wrote:

 Was Google charging ISPs for this service?

 Cheers
 Ryan


 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Gary Greene
 Sent: Tuesday, August 18, 2015 2:18 PM
 To: Shawn L sha...@up.net
 Cc: nanog nanog@nanog.org
 Subject: Re: Google Apps for ISPs -- Lingering fallout

 You’ll need to escalate this with Google. If the front-end support team
 cannot help, move up the chain as far as you can. It should eventually
 reach the PM that worked on the turn-down of that service and get some
 action.

 --
 Gary L. Greene, Jr.
 Sr. Systems Administrator
 IT Operations
 Minerva Networks, Inc.
 Cell: +1 (650) 704-6633




  On Aug 18, 2015, at 10:39 AM, Shawn L sha...@up.net wrote:
 
 
  I know there are others on this list who used Google Apps for ISPs and
 recently migrated off (as the service was discontinued).
 
  We have had several cases where the user had a YouTube channel or Picasa
 photo albums, etc. that they created with their Google Apps for ISPs
 credentials.  Now that the service is gone, those channels and albums still
 exist but the users are unable to login to them or manage them in any way
 because it tells them that their account has been disabled.
 
  Of course, Google had been un-responsive to all of our (and the
 customer's) inquiries about how to fix this.
 
  Has anyone else run into this and found a way around it?
 
  thanks
 
 
  Shawn
 

Re: Google Apps for ISPs -- Lingering fallout

[Scott Helms]

Ryan,

From what I've seen a myriad of solutions.  A lot of the people I know that
wanted a full functionality replacement switched to Hyperoffice:
http://www.hyperoffice.com/sp/google-apps.php

Some others went to Zimbra:
https://www.zimbra.com/

Others went to a variety of less functional but also less expensive
solutions that look more like traditional ISP email.

It really depended on how much the ISP thought their end users wanted the
Google like functionality.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Mon, Aug 24, 2015 at 9:15 AM, Ryan Finnesey r...@finnesey.com wrote:

 I have been working on putting together a program to work with ISPs to
 offer Office 365 I was thinking the Google Apps for ISP shutdown would be
 an opportunity but it seem to be a very different price point.  I have done
 a large number of Google App to Office 365 migration but Google was
 charging  around $12 per user.Also a lot within the nonprofit space
  witch is a free license.  What system did most ISPs move to?



 Cheers

 Ryan





 *From:* Scott Helms [mailto:khe...@zcorum.com]
 *Sent:* Monday, August 24, 2015 8:35 AM
 *To:* Ryan Finnesey r...@finnesey.com
 *Cc:* Gary Greene ggre...@minervanetworks.com; Shawn L sha...@up.net;
 nanog nanog@nanog.org
 *Subject:* Re: Google Apps for ISPs -- Lingering fallout



 Ryan,



 Most certainly, the charges varied some  because of size and other factors
 but it was around 25 cents monthly per Gmail box.




 Scott Helms
 Vice President of Technology
 ZCorum
 (678) 507-5000
 
 http://twitter.com/kscotthelms
 



 On Mon, Aug 24, 2015 at 1:43 AM, Ryan Finnesey r...@finnesey.com wrote:

 Was Google charging ISPs for this service?

 Cheers
 Ryan


 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Gary Greene
 Sent: Tuesday, August 18, 2015 2:18 PM
 To: Shawn L sha...@up.net
 Cc: nanog nanog@nanog.org
 Subject: Re: Google Apps for ISPs -- Lingering fallout

 You’ll need to escalate this with Google. If the front-end support team
 cannot help, move up the chain as far as you can. It should eventually
 reach the PM that worked on the turn-down of that service and get some
 action.

 --
 Gary L. Greene, Jr.
 Sr. Systems Administrator
 IT Operations
 Minerva Networks, Inc.
 Cell: +1 (650) 704-6633




  On Aug 18, 2015, at 10:39 AM, Shawn L sha...@up.net wrote:
 
 
  I know there are others on this list who used Google Apps for ISPs and
 recently migrated off (as the service was discontinued).
 
  We have had several cases where the user had a YouTube channel or Picasa
 photo albums, etc. that they created with their Google Apps for ISPs
 credentials.  Now that the service is gone, those channels and albums still
 exist but the users are unable to login to them or manage them in any way
 because it tells them that their account has been disabled.
 
  Of course, Google had been un-responsive to all of our (and the
 customer's) inquiries about how to fix this.
 
  Has anyone else run into this and found a way around it?
 
  thanks
 
 
  Shawn
 

Re: Google Apps for ISPs -- Lingering fallout

[Scott Helms]

Matt,

That's what I thought, but it was even more expensive if you decided you
wanted the ad free version.  The folks at Google I spoke with countered
with the costs for Google Apps for Business and placed Partner Edition (the
one for ISPs) between the direct consumer Gmail offering and the business
offerings in functionality and pricing.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Mon, Aug 24, 2015 at 8:45 AM, Matt Hoppes mhop...@indigowireless.com
wrote:

 Which is odd. Considering it was basically gmail on the back end and they
 still got ad revenue from it.



  On Aug 24, 2015, at 08:34, Scott Helms khe...@zcorum.com wrote:
 
  Ryan,
 
  Most certainly, the charges varied some  because of size and other
 factors
  but it was around 25 cents monthly per Gmail box.
 
 
  Scott Helms
  Vice President of Technology
  ZCorum
  (678) 507-5000
  
  http://twitter.com/kscotthelms
  
 
  On Mon, Aug 24, 2015 at 1:43 AM, Ryan Finnesey r...@finnesey.com
 wrote:
 
  Was Google charging ISPs for this service?
 
  Cheers
  Ryan
 
 
  -Original Message-
  From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Gary Greene
  Sent: Tuesday, August 18, 2015 2:18 PM
  To: Shawn L sha...@up.net
  Cc: nanog nanog@nanog.org
  Subject: Re: Google Apps for ISPs -- Lingering fallout
 
  You’ll need to escalate this with Google. If the front-end support team
  cannot help, move up the chain as far as you can. It should eventually
  reach the PM that worked on the turn-down of that service and get some
  action.
 
  --
  Gary L. Greene, Jr.
  Sr. Systems Administrator
  IT Operations
  Minerva Networks, Inc.
  Cell: +1 (650) 704-6633
 
 
 
 
  On Aug 18, 2015, at 10:39 AM, Shawn L sha...@up.net wrote:
 
 
  I know there are others on this list who used Google Apps for ISPs and
  recently migrated off (as the service was discontinued).
 
  We have had several cases where the user had a YouTube channel or
 Picasa
  photo albums, etc. that they created with their Google Apps for ISPs
  credentials.  Now that the service is gone, those channels and albums
 still
  exist but the users are unable to login to them or manage them in any
 way
  because it tells them that their account has been disabled.
 
  Of course, Google had been un-responsive to all of our (and the
  customer's) inquiries about how to fix this.
 
  Has anyone else run into this and found a way around it?
 
  thanks
 
 
  Shawn
 
 
 

Re: RES: Exploits start against flaw that could hamstring huge swaths of

[Scott Helms]

Automation just means your mistake goes many more places more quickly.
On Aug 4, 2015 9:38 AM, Christopher Morrow morrowc.li...@gmail.com
wrote:

 On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms khe...@zcorum.com wrote:
  With the (large) caveat that heterogenous networks are more subject to
  human error in many cases.

 coughautomate!/cough

  On Aug 4, 2015 9:25 AM, Joe Greco jgr...@ns.sol.net wrote:
 
   So, you guys recommend replace Bind for another option ?
 
  No.  Replacing one occasionally faulty product with another occasionally
  faulty product is foolish.  There's no particular reason to think that
  another product will be impervious to code bugs.  What I was suggesting
  was to use several different devices, much as some networks prefer to
  buy some Cisco gear and some Juniper gear and make them redundant, or
  as a well-built ZFS storage array consists of drives from different
  manufacturers.
 
  Heterogeneous environments tend to be more resilient because they are
  less likely to all suffer the same defect at once.  Problems still
 result
  in some pain and trouble, but it usually doesn't result in a service
  outage.
 
  This doesn't seem like a horribly catastrophic bug in any case.  Anyone
  who is reliant on a critical bit like a DNS server probably has it set
  up to automatically restart if it doesn't exit cleanly.  If you don't,
  you should!
 
  So if it matters to you, I suggest that you instead use a combination
  of different products, and you'll be more resilient.  If you have two
  recursers for your customers, one can be BIND and one can be Unbound.
  And when some critical vuln comes along and knocks out Unbound, you'll
  still be resolving names.  Ditto BIND.  You're not likely to see both
  happen at the same time.
 
  However, at least here, we actually *use* TSIG updates, and other
  functionality that'd be hard to replace (BIND9 is pretty much THE only
  option for some functionality).
 
  ... JG
  --
  Joe Greco - sol.net Network Services - Milwaukee, WI -
 http://www.sol.net
  We call it the 'one bite at the apple' rule. Give me one chance [and]
  then I
  won't contact you again. - Direct Marketing Ass'n position on e-mail
  spam(CNN)
  With 24 million small businesses in the US alone, that's way too many
  apples.
 

Re: RES: Exploits start against flaw that could hamstring huge swaths of

[Scott Helms]

With the (large) caveat that heterogenous networks are more subject to
human error in many cases.
On Aug 4, 2015 9:25 AM, Joe Greco jgr...@ns.sol.net wrote:

  So, you guys recommend replace Bind for another option ?

 No.  Replacing one occasionally faulty product with another occasionally
 faulty product is foolish.  There's no particular reason to think that
 another product will be impervious to code bugs.  What I was suggesting
 was to use several different devices, much as some networks prefer to
 buy some Cisco gear and some Juniper gear and make them redundant, or
 as a well-built ZFS storage array consists of drives from different
 manufacturers.

 Heterogeneous environments tend to be more resilient because they are
 less likely to all suffer the same defect at once.  Problems still result
 in some pain and trouble, but it usually doesn't result in a service
 outage.

 This doesn't seem like a horribly catastrophic bug in any case.  Anyone
 who is reliant on a critical bit like a DNS server probably has it set
 up to automatically restart if it doesn't exit cleanly.  If you don't,
 you should!

 So if it matters to you, I suggest that you instead use a combination
 of different products, and you'll be more resilient.  If you have two
 recursers for your customers, one can be BIND and one can be Unbound.
 And when some critical vuln comes along and knocks out Unbound, you'll
 still be resolving names.  Ditto BIND.  You're not likely to see both
 happen at the same time.

 However, at least here, we actually *use* TSIG updates, and other
 functionality that'd be hard to replace (BIND9 is pretty much THE only
 option for some functionality).

 ... JG
 --
 Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
 We call it the 'one bite at the apple' rule. Give me one chance [and]
 then I
 won't contact you again. - Direct Marketing Ass'n position on e-mail
 spam(CNN)
 With 24 million small businesses in the US alone, that's way too many
 apples.

Re: RES: Exploits start against flaw that could hamstring huge swaths of

[Scott Helms]

I don't disagree, but automation usually protects against typing errors, it
doesn't protect against incorrect configurations.  Using multiple vendors
or server software means that your people have to know all of the systems.
There are many cases where, for example, a Cisco like CLI will make a
network engineer think that a command works exactly the same way on another
vendors system when in fact the under the hood implementation is very
different.

It's not always feasible to have the people with the needed skill levels
and automation does not help that at all.
On Aug 4, 2015 10:21 AM, Christopher Morrow morrowc.li...@gmail.com
wrote:

 On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms khe...@zcorum.com wrote:
  Automation just means your mistake goes many more places more quickly.
 

 and letting people keep poking at things that computers should be
 doing is... much worse. people do not have reliability and
 repeat-ability over time.


 If you fear 'many more places' problems, improve your testing.

  On Aug 4, 2015 9:38 AM, Christopher Morrow morrowc.li...@gmail.com
  wrote:
 
  On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms khe...@zcorum.com wrote:
   With the (large) caveat that heterogenous networks are more subject to
   human error in many cases.
 
  coughautomate!/cough
 
   On Aug 4, 2015 9:25 AM, Joe Greco jgr...@ns.sol.net wrote:
  
So, you guys recommend replace Bind for another option ?
  
   No.  Replacing one occasionally faulty product with another
   occasionally
   faulty product is foolish.  There's no particular reason to think
 that
   another product will be impervious to code bugs.  What I was
 suggesting
   was to use several different devices, much as some networks prefer to
   buy some Cisco gear and some Juniper gear and make them redundant, or
   as a well-built ZFS storage array consists of drives from different
   manufacturers.
  
   Heterogeneous environments tend to be more resilient because they are
   less likely to all suffer the same defect at once.  Problems still
   result
   in some pain and trouble, but it usually doesn't result in a service
   outage.
  
   This doesn't seem like a horribly catastrophic bug in any case.
 Anyone
   who is reliant on a critical bit like a DNS server probably has it
 set
   up to automatically restart if it doesn't exit cleanly.  If you
 don't,
   you should!
  
   So if it matters to you, I suggest that you instead use a combination
   of different products, and you'll be more resilient.  If you have two
   recursers for your customers, one can be BIND and one can be Unbound.
   And when some critical vuln comes along and knocks out Unbound,
 you'll
   still be resolving names.  Ditto BIND.  You're not likely to see both
   happen at the same time.
  
   However, at least here, we actually *use* TSIG updates, and other
   functionality that'd be hard to replace (BIND9 is pretty much THE
 only
   option for some functionality).
  
   ... JG
   --
   Joe Greco - sol.net Network Services - Milwaukee, WI -
   http://www.sol.net
   We call it the 'one bite at the apple' rule. Give me one chance
 [and]
   then I
   won't contact you again. - Direct Marketing Ass'n position on e-mail
   spam(CNN)
   With 24 million small businesses in the US alone, that's way too many
   apples.
  

Re: Windows 10 Release

[Scott Helms]

I was just thinking about my remaining Win 7 box _after_ I hit send and I
believe you're correct (I have one still to upgrade).  Which means users
upgrading from 7 to 10 will need to create an ID, but users of 8 and 8.1
will use the one they already have.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Thu, Jul 30, 2015 at 10:23 AM, Brooks Bridges 
bro...@firestormnetworks.net wrote:

 Just as a point of debate, I've been using Windows 7 for quite some time
 and I do not, nor have I ever, given MS any email information or have I
 created a Live account.

 On 7/30/2015 7:19 AM, Scott Helms wrote:

 Since the requirement is that users are upgrading from Win 7, 8, or 8.1
 they've already had to create at least a minimal MS ID which means either
 creating an email account on Outlook.com or providing an existing email
 address and  a password for MS.


 Scott Helms
 Vice President of Technology
 ZCorum
 (678) 507-5000
 
 http://twitter.com/kscotthelms
 

 On Thu, Jul 30, 2015 at 10:15 AM, Matthew Black matthew.bl...@csulb.edu
 wrote:

  Are users required to create any type of Microsoft cloud account (e.g.,
 OneDrive, Office365, et alil) in order to install and use Windows 10? Of
 Office? Is it possible to simply use Windows 10 without any Microsoft or
 Google or Yahoo accounts?

 Is the unique identifier available to advertisers only through IE (or its
 successor) OR will it also be available through Firefox/Chrome?


 matthew black
 california state university, long beach

Re: Windows 10 Release

[Scott Helms]

Justin,

That's true, but it takes effort for people to either set up a local
account or change to one, and very few consumers will do that or have.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Thu, Jul 30, 2015 at 10:28 AM, Justin Mckillican jus...@mckill.ca
wrote:

 Nope.  For the upgrade the only piece of information MSFT needed was your
 email if you chose email notification once the upgrade was ready for you.

 After it's installed it will ask to finish up the install the 'Express'
 method which enabled a bunch of things like WIFI password sharing to
 friends and whatever else or if you chose the manual option like I did you
 can disable everything.  It will also inherit your existing user settings,
 so if your user is a local one instead of a cloud one it will continue to
 be that way.

 It does install One Drive but again, if you never configured it or used it
 then you'll simply see it in your task bar with the welcome or signup
 screen.


 -justin

  On Jul 30, 2015, at 10:19 AM, Scott Helms khe...@zcorum.com wrote:
 
  Since the requirement is that users are upgrading from Win 7, 8, or 8.1
  they've already had to create at least a minimal MS ID which means either
  creating an email account on Outlook.com or providing an existing email
  address and  a password for MS.
 
 
  Scott Helms
  Vice President of Technology
  ZCorum
  (678) 507-5000
  
  http://twitter.com/kscotthelms
  
 
  On Thu, Jul 30, 2015 at 10:15 AM, Matthew Black matthew.bl...@csulb.edu
 
  wrote:
 
  Are users required to create any type of Microsoft cloud account (e.g.,
  OneDrive, Office365, et alil) in order to install and use Windows 10? Of
  Office? Is it possible to simply use Windows 10 without any Microsoft or
  Google or Yahoo accounts?
 
  Is the unique identifier available to advertisers only through IE (or
 its
  successor) OR will it also be available through Firefox/Chrome?
 
 
  matthew black
  california state university, long beach
 

Re: Windows 10 Release

[Scott Helms]

Since the requirement is that users are upgrading from Win 7, 8, or 8.1
they've already had to create at least a minimal MS ID which means either
creating an email account on Outlook.com or providing an existing email
address and  a password for MS.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Thu, Jul 30, 2015 at 10:15 AM, Matthew Black matthew.bl...@csulb.edu
wrote:

 Are users required to create any type of Microsoft cloud account (e.g.,
 OneDrive, Office365, et alil) in order to install and use Windows 10? Of
 Office? Is it possible to simply use Windows 10 without any Microsoft or
 Google or Yahoo accounts?

 Is the unique identifier available to advertisers only through IE (or its
 successor) OR will it also be available through Firefox/Chrome?


 matthew black
 california state university, long beach

Re: Windows 10 Release

[Scott Helms]

It's downloading for me right now, though I did reserve my slot.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Tue, Jul 28, 2015 at 4:49 PM, Justin Mckillican jus...@mckill.ca wrote:

 For upgraders I believe only 5 million 'Insiders' that tested Windows 10
 will get it tomorrow.   The rest of the free upgraders (those from Win7 and
 Win8) will get it over the next two weeks at different times with the
 priority going to those that 'reserved' it in Windows Update tool.


 -justin

  On Jul 28, 2015, at 4:45 PM, Nick Olsen n...@flhsi.com wrote:
 
  Anyone anxious to see what kind of traffic comes from Windows 10
 releasing
  tomorrow?
 
  Being a 3-4GB download. Each device is moving more data than any Apple
  update ever did.
 
  Wonder if they'll stage the release as apple appeared to have learned
  after IOS7 hammered a bunch of networks.
 
  Nick Olsen
  Network Operations  (855) FLSPEED  x106
 

Re: DOCSIS CMTS Systems

[Scott Helms]

Colton,

Pico is a decent solution, Harmonic has one too (
http://www.harmonicinc.com/product/cable-edge/nsg-exo).  As for cable
specific lists, about the closest I know about is the SCTE mailing list.

http://www.scte.org/SCTE/Resources/SCTE_Lists.aspx


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Wed, Jul 29, 2015 at 9:27 AM, Colton Conor colton.co...@gmail.com
wrote:

 We are servicing more MDU customers that have older buildings. There is no
 CAT5E installed, so extremely old phone cable or coaxial TV cable seems to
 be our only inside wire options. There is no easy and inexpensive way to
 run new cable, so we must deal with what is available.

 We are very familiar with the VDSL2 offerings to be able to use the phone
 cable, but know nothing about CMTS solutions available.DOCSIS 3.0 capable
 modems seem to be much more inexpensive than VDSL2 capable modems.

 We are looking for recommendations on small CMTS systems for MDU's. I
 would expect we would want at least DOCSIS 3.0 capabilities, and I
 assume DOCSIS 3.1 is too new and expensive to deploy on a small scale
 (think 50 to 200 units per property). We would need the full solution to
 manage and maintain such an offering.

 I was thinking something like this might be a good fit:
 http://www.picodigital.com/product-details.php?ID=miniCMTS200a which is
 available new for $4500 online.

 For those of you deploying CMTS systems what do you use and recommend?

 I am not sure if there is a cable equivalent list to NANOG, but if so
 please let me know.

Re: Google Apps for ISPs

[Scott Helms]

We worked with dozens of service providers to get their email services
migrated, AFAIK no one got an extension.  I was told directly that it was
possible to have an extension because Google was pulling down the entire
system.  I'd advise:

1)  Make sure your domain TTL's are fairly low so you can change your MX
record and have the world get that update shortly there after.

2)  Find an alternative email provider, preferably someone who has done
transitions to and from Google before.

3)  Start communicating with your customers, AFAIK their email, address
books, and calendars aren't available and won't be.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Thu, Jun 18, 2015 at 11:58 AM, Josh Luthman j...@imaginenetworksllc.com
wrote:

 If anyone can message me off list it would be great.

 We were originally told the service would be shut off in July. All of the
 accounts were disabled June 9.

 Josh Luthman
 Office: 937-552-2340
 Direct: 937-552-2343
 1100 Wayne St
 Suite 1337
 Troy, OH 45373

Re: Google Apps for ISPs

[Scott Helms]

Josh,

From what I have been able to see from an outsider's point of view, they
tore down the virtual machines that held those emails and while I doubt
they scrubbed the hard drives, they're not available in commercially
reasonable way.

No ISP I've worked with has been able to get access to emails, settings,
address books, or anything else since early in June and that's not from
lack of trying.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Thu, Jun 18, 2015 at 12:32 PM, Josh Luthman j...@imaginenetworksllc.com
wrote:

 That's all we're after, customers' emails.

 Josh Luthman
 Office: 937-552-2340
 Direct: 937-552-2343
 1100 Wayne St
 Suite 1337
 Troy, OH 45373
 On Jun 18, 2015 12:12 PM, Scott Helms khe...@zcorum.com wrote:

 We worked with dozens of service providers to get their email services
 migrated, AFAIK no one got an extension.  I was told directly that it was
 possible to have an extension because Google was pulling down the entire
 system.  I'd advise:

 1)  Make sure your domain TTL's are fairly low so you can change your MX
 record and have the world get that update shortly there after.

 2)  Find an alternative email provider, preferably someone who has done
 transitions to and from Google before.

 3)  Start communicating with your customers, AFAIK their email, address
 books, and calendars aren't available and won't be.


 Scott Helms
 Vice President of Technology
 ZCorum
 (678) 507-5000
 
 http://twitter.com/kscotthelms
 

 On Thu, Jun 18, 2015 at 11:58 AM, Josh Luthman 
 j...@imaginenetworksllc.com wrote:

 If anyone can message me off list it would be great.

 We were originally told the service would be shut off in July. All of the
 accounts were disabled June 9.

 Josh Luthman
 Office: 937-552-2340
 Direct: 937-552-2343
 1100 Wayne St
 Suite 1337
 Troy, OH 45373

Re: PPPoE/IPoE, any recommendations for upgrade?

[Scott Helms]

There are alternative solutions.  We're looking at using one from ABN for a
customer that perseveres all of the AAA functionality and supports IPoE
with the same integrationhooks as PPPoE and handles both at the same time
to make transition easier.  The project is being staged right now but
anyone who wants to be kept in the loop in how it goes can contact me off
list.
On Jun 8, 2015 11:34 PM, Colton Conor colton.co...@gmail.com wrote:

 Suspend or shut down a user is easy, just disable their port on the DSLAM
 or change their port to a VLAN that only allows them to access/pay their
 bill.

 Going to PPPoE to IPoE increases the net throughput right?

 On Mon, Jun 8, 2015 at 1:16 AM, Nasser Heidari nas...@rasana.net wrote:

   On Sun, 7 Jun 2015, Mikael Abrahamsson wrote:
  
- If you are already using IPoE, tell more why should I upgrade?
  
   The IPoE and IPoEoADSL I have done didn't need radius, didn't need BNG,
  didn't
   need a lot of the complications you're talking about. It could
 basically
  be realised in
   any decent L3 switch as default gateway for the customers instead of
  needing BNG.
  
   So I'd say if you want to get full potential of IPoE you need to do
  simplification as
   well, otherwise there is little use in doing the work if he only thing
  you
  want to
   change is from IPoPPPoE to IPoE encapsulation and keep all the other
  stuff
  you're
   doing.
  
   IPoPPPoE requires special CPE and router at your end to achieve high
  speeds,
   because they need to support encapsulation/decapsulation of packets at
  whatever
   speed you provide. The number of devices that do this is a lot smaller
  than the
   ones that do decent speeds with just IPoE.
  
   So some people will say migrating to IPoE from IPoPPPoE buys them
  nothing,
   because they feel they need all the mechanisms they currently use.
   Greenfield deployments might say hey, we can do this without a lot of
  the
  needed
   mechanisms for IPoPPPoE and save a lot of money and complication.
  
   --
   Mikael Abrahamssonemail: swm...@swm.pp.se
 
  Thanks for your reply. I'm would like this simplicity if I could keep
 same
  functionalities I have in PPPoE. By functionalities I mean:
  - AAA
  - Triple-ply services and classified accounting per service
  - Possibility to suspend a user service in case of over-quota
  - applying fair-share policies
 
  Do I have any option to have simplicity and same functionality together?
 
  Regards,
  Nasser
 

Re: ADSL Line Extenders

[Scott Helms]

They're certainly real, still in use, and deployed world wide but most
commonly in rural areas.  They aren't particularly cost effective for most
scenarios, but cheaper than hanging even a mini-DSLAM to service 1-2
customers that are too far away from a cabinet.  Installing them is a pain
and keeping them running long term is an even bigger pain.  Certain models
don't work well with specific DSLAMs and/or in specific plant combinations
so testing with your DSLAMs, modems, and in your plant is a must.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Tue, Apr 28, 2015 at 5:24 PM, Jean-Francois Mezei 
jfmezei_na...@vaxination.ca wrote:


 A friend on a rural DSl association asked about ADSL line extenders.

 A search on Google yields many products dating back to the days of
 ADSL-1 advertising 1mbps profiles, but a few seem more recent and
 support ADSL2+ (not sure if any support VDSL2).

 Are these thing out of date and no longer deployed ? Were they ever
 effective, or just vapourware that didn't really improve things ?


 Do any Telcos still deploy them ?  Anyone know of deployments in Canada ?

 I just need a reality check on those devices.

 jf

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

Barry,

First, I want to apologize.  I (badly) misread your email, but in case I
should not have responded that way.  I would have gotten this out sooner,
but I was traveling back from the CableLabs conference.


Second, my assertion is simply that Usenet servers aren't automagically
symmetrical in their bandwidth usage and that trying to build a system off
of NNTP so that each broadband subscriber became in effect a Usenet server
wouldn't work well without significant modifications.

Third, if anyone cares the Usenet server we ran was news.america.net


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Tue, Mar 3, 2015 at 3:29 PM, Barry Shein b...@world.std.com wrote:


 From: Scott Helms khe...@zcorum.com
 
 /em shrug
 
 I can't help it if you don't like real world data.
 On Mar 3, 2015 2:25 PM, Barry Shein b...@world.std.com wrote:
 
 
  Ok, then I no longer have any confidence that I understand what you
  were asserting.

 Generally when someone says they don't understand me I assume it's my
 fault for not being clear and try to clarify.

 Apparently you prefer to be rude.

 *Plonk*

 --
 -Barry Shein

 The World  | b...@theworld.com   |
 http://www.TheWorld.com
 Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR,
 Canada
 Software Tool  Die| Public Access Internet | SINCE 1989 *oo*

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

/em shrug

I can't help it if you don't like real world data.
On Mar 3, 2015 2:25 PM, Barry Shein b...@world.std.com wrote:


 Ok, then I no longer have any confidence that I understand what you
 were asserting.

 From: Scott Helms khe...@zcorum.com
 Odd how the graphing for the top 1000 Usenet servers showed exactly the
 pattern I predicted.
 On Mar 2, 2015 3:46 PM, Barry Shein b...@world.std.com wrote:
 
 
Anything based on NNTP would be extremely asymmetric without
 significant
changes to the protocol or human behavior.
   
We ran significant Usenet servers with binaries for nearly 20 years
 and
without for another 5 and the servers' traffic was heavily
 asymmetric.
On Mar 1, 2015 9:11 AM, Miles Fidelman mfidel...@meetinghouse.net
 
  wrote:
 
  With all due respect it's like people act purposely obtuse just to
  argue.
 
  If you're a Usenet server (and most likely client) then it'll be
  somewhat symmetric.
 
  Depending on how many nodes you serve the bias could easily be towards
  upload bandwidth as msgs come in once (ideally) but you flood them to
  all the other servers you serve once per server, the entire traffic
  goes out multiple times, plus or minus various optimizations like
  already have that msg oh for the love of all that is good and holy
  do I have to type the entire NNTP protocol spec in here just to make
  sure there isn't some microscopic crack of light someone can use to
  misinterpret and/or pick nits about???
 
  What was the original question because I think this has degenerated
  into just argumentativeness, we're on the verge of spelling and
  grammar error flames.
 
  I don't know how anyone who claims to have run Usenet servers couldn't
  know all this, is it just trolling?
 
  --
  -Barry Shein
 
  The World  | b...@theworld.com   |
  http://www.TheWorld.com
  Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR,
  Canada
  Software Tool  Die| Public Access Internet | SINCE 1989
  *oo*

 --
 -Barry Shein

 The World  | b...@theworld.com   |
 http://www.TheWorld.com
 Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR,
 Canada
 Software Tool  Die| Public Access Internet | SINCE 1989 *oo*

Re: FCC form 477 geocoding

[Scott Helms]

Are you trying to get the census tract for each customer?  If so you can
get that from most of the gecoding services like Esri etc.
On Mar 3, 2015 5:38 PM, Jay Hennigan j...@west.net wrote:

 The CFO here is working on FCC form 477 and tells me that he needs to
 enter census tract and block information for our customers. He says that
 the US Census site is worse than useless and the info isn't on the FCC
 site.

 What are others doing in this regard?

 --
 --
 Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
 Impulse Internet Service  -  http://www.impulse.net/
 Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: content regulation, was Verizon Policy Statement on Net Neutrality

[Scott Helms]

San Jose is most certainly not a pure coax network and is HFC.

HSD does mean High Speed Data.
On Mar 2, 2015 3:26 PM, Owen DeLong o...@delong.com wrote:

 Not so sure about that…

 240.59.103.76.in-addr.arpa. 7200 IN  PTR
 c-76-103-59-240.hsd1.ca.comcast.net.

 is most definitely a business class service from Comcast. Seems to match
 the entry for 24.7.48.153 pretty closely.

 I think the difference is the type of cable network in the particular
 area. HFC is Hybrid Fiber Coax. The network in San Jose doesn’t really have
 any fiber, so it’s likely not an HFC network. I’m not sure what HSD stands
 for other than possibly “High Speed Data”, but I suspect it’s more likely
 some cable-specific term for an all-copper alternative to HFC.

 Owen

  On Mar 2, 2015, at 03:39 , Rich Kulawiec r...@gsp.org wrote:
 
  On Sun, Mar 01, 2015 at 11:58:34AM -0500, Christopher Morrow wrote:
  business vs consumer edition products? (that'd be my bet)
 
  I think these are all residential customers, as business customers
  appear to use different subdomains and/or host naming conventions, e.g.:
 
24.7.48.153 c-24-7-48-153.hsd1.ca.comcast.net
24.10.217.142   c-24-10-217-142.hsd1.ut.comcast.net
24.129.85.220   c-24-129-85-220.hsd1.fl.comcast.net
  vs.
70.88.25.201
 70-88-25-201-chesterfield-va.hfc.comcastbusiness.net
70.90.158.3770-90-158-37-knoxville.hfc.comcastbusiness.net
70.91.133.105   70-91-133-105-ma-ne.hfc.comcastbusiness.net
 
  Or:
23.240.176.98   cpe-23-240-176-98.socal.res.rr.com
24.25.253.81cpe-24-25-253-81.hawaii.res.rr.com
24.27.121.156   cpe-24-27-121-156.tx.res.rr.com
  vs.
24.106.98.106   rrcs-24-106-98-106.central.biz.rr.com
24.142.142.169  rrcs-24-142-142-169.central.biz.rr.com
24.173.100.134  rrcs-24-173-100-134.sw.biz.rr.com
 
  Those are all (very recent) direct-to-MX on port 25 spam sources, but it
  looks to me like the first group in each set is residential and the
 second
  group is business.  But perhaps I'm misinterpreting the naming.
 
  ---rsk

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

Odd how the graphing for the top 1000 Usenet servers showed exactly the
pattern I predicted.
On Mar 2, 2015 3:46 PM, Barry Shein b...@world.std.com wrote:


   Anything based on NNTP would be extremely asymmetric without significant
   changes to the protocol or human behavior.
  
   We ran significant Usenet servers with binaries for nearly 20 years and
   without for another 5 and the servers' traffic was heavily asymmetric.
   On Mar 1, 2015 9:11 AM, Miles Fidelman mfidel...@meetinghouse.net
 wrote:

 With all due respect it's like people act purposely obtuse just to
 argue.

 If you're a Usenet server (and most likely client) then it'll be
 somewhat symmetric.

 Depending on how many nodes you serve the bias could easily be towards
 upload bandwidth as msgs come in once (ideally) but you flood them to
 all the other servers you serve once per server, the entire traffic
 goes out multiple times, plus or minus various optimizations like
 already have that msg oh for the love of all that is good and holy
 do I have to type the entire NNTP protocol spec in here just to make
 sure there isn't some microscopic crack of light someone can use to
 misinterpret and/or pick nits about???

 What was the original question because I think this has degenerated
 into just argumentativeness, we're on the verge of spelling and
 grammar error flames.

 I don't know how anyone who claims to have run Usenet servers couldn't
 know all this, is it just trolling?

 --
 -Barry Shein

 The World  | b...@theworld.com   |
 http://www.TheWorld.com
 Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR,
 Canada
 Software Tool  Die| Public Access Internet | SINCE 1989 *oo*

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

Daniel,

The sold speeds are all actually less than the actual speeds. The PON
customers are slightly over provisioned and the DOCSIS customers are over
provisioned a bit more.
On Mar 2, 2015 10:01 AM, Daniel Taylor dtay...@vocalabs.com wrote:

 What do those 25 and 50Mb/s download rates amount to in practice?

 Statistically speaking, those might *be* symmetric.

 On 03/02/2015 08:41 AM, Scott Helms wrote:


 Daniel,
 For the third or fourth time in this discussion we are tracking and
 customer satisfaction for users who do have symmetrical bandwidth 24 mbps
 and have for a number of years.

 We see customer usage patterns and satisfaction being statically the same
 on 25/25 and 25/8 accounts.  The same is true when we look at 50/50 versus
 50/12 accounts.

 On Mar 2, 2015 9:22 AM, Daniel Taylor dtay...@vocalabs.com mailto:
 dtay...@vocalabs.com wrote:

 I'm clearly not a normal user, or I wouldn't be here.
 Normal users have never experienced high-speed symmetrical service.

 People don't miss what they have never had.

 On 03/02/2015 08:09 AM, Scott Helms wrote:


 That's not the norm for consumers, but the important thing to
 understand is that for most of the technologies we use for
 broadband there simply is less upstream capacity than
 downstream.  That upstream scarcity means that for DSL,
 DOCSIS, PON, WiFi, and LTE delivering symmetrical upstream
 bandwidth will cost the service provider more which means at
 some point it will cost consumers more.

 WiFi is a special case, while there is no theoretical reason
 it must be asymmetrical but it works that way in practice
 because dedicated APs invariably have both higher transmit
 power and much better antenna gain.  The average AP in the US
 will put out a watt or more while clients are putting out ~250
 milliwatts and with 0 antenna gain.

 On Mar 2, 2015 8:58 AM, Daniel Taylor dtay...@vocalabs.com
 mailto:dtay...@vocalabs.com mailto:dtay...@vocalabs.com
 mailto:dtay...@vocalabs.com wrote:

 Personally?
 If the price were the same, I'd go with 50/50.

 That way my uploads would take even less time.

 It isn't about the averaged total, it's about how long
 each event
 takes, and backing up 4GB of files off-site shouldn't have
 to take
 an hour.

 On 02/27/2015 03:11 PM, Scott Helms wrote:

 Daniel,


 50MB/s might be tough to fill, but even at home I can get
 good use out of the odd 25MB/s upstream burst for a
 few minutes.

 Which would you choose, 50/50 or 75/25?  My point is
 not that
 upstream speed isn't valuable, but merely that demand
 for it
 isn't symmetrical and unless the market changes won't
 be in
 the near term.  Downstream demand is growing, in most
 markets
 I can see, much faster than upstream demand.



 Scott Helms
 Vice President of Technology
 ZCorum
 (678) 507-5000 tel:%28678%29%20507-5000
 tel:%28678%29%20507-5000
 
 http://twitter.com/kscotthelms
 



 -- Daniel Taylor  VP Operations Vocal
 Laboratories, Inc.
 dtay...@vocalabs.com mailto:dtay...@vocalabs.com
 mailto:dtay...@vocalabs.com mailto:dtay...@vocalabs.com
 http://www.vocalabs.com/ (612)235-5711 tel:%28612%29235-5711
 tel:%28612%29235-5711



 -- Daniel Taylor  VP OperationsVocal
 Laboratories, Inc.
 dtay...@vocalabs.com mailto:dtay...@vocalabs.com
 http://www.vocalabs.com/ (612)235-5711 tel:%28612%29235-5711



 --
 Daniel Taylor  VP OperationsVocal Laboratories, Inc.
 dtay...@vocalabs.com   http://www.vocalabs.com/(612)235-5711

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

Daniel,
For the third or fourth time in this discussion we are tracking and
customer satisfaction for users who do have symmetrical bandwidth 24 mbps
and have for a number of years.

We see customer usage patterns and satisfaction being statically the same
on 25/25 and 25/8 accounts.  The same is true when we look at 50/50 versus
50/12 accounts.
On Mar 2, 2015 9:22 AM, Daniel Taylor dtay...@vocalabs.com wrote:

 I'm clearly not a normal user, or I wouldn't be here.
 Normal users have never experienced high-speed symmetrical service.

 People don't miss what they have never had.

 On 03/02/2015 08:09 AM, Scott Helms wrote:


 That's not the norm for consumers, but the important thing to understand
 is that for most of the technologies we use for broadband there simply is
 less upstream capacity than downstream.  That upstream scarcity means that
 for DSL, DOCSIS, PON, WiFi, and LTE delivering symmetrical upstream
 bandwidth will cost the service provider more which means at some point it
 will cost consumers more.

 WiFi is a special case, while there is no theoretical reason it must be
 asymmetrical but it works that way in practice because dedicated APs
 invariably have both higher transmit power and much better antenna gain.
 The average AP in the US will put out a watt or more while clients are
 putting out ~250 milliwatts and with 0 antenna gain.

 On Mar 2, 2015 8:58 AM, Daniel Taylor dtay...@vocalabs.com mailto:
 dtay...@vocalabs.com wrote:

 Personally?
 If the price were the same, I'd go with 50/50.

 That way my uploads would take even less time.

 It isn't about the averaged total, it's about how long each event
 takes, and backing up 4GB of files off-site shouldn't have to take
 an hour.

 On 02/27/2015 03:11 PM, Scott Helms wrote:

 Daniel,


 50MB/s might be tough to fill, but even at home I can get
 good use out of the odd 25MB/s upstream burst for a few minutes.

 Which would you choose, 50/50 or 75/25?  My point is not that
 upstream speed isn't valuable, but merely that demand for it
 isn't symmetrical and unless the market changes won't be in
 the near term.  Downstream demand is growing, in most markets
 I can see, much faster than upstream demand.



 Scott Helms
 Vice President of Technology
 ZCorum
 (678) 507-5000 tel:%28678%29%20507-5000
 
 http://twitter.com/kscotthelms
 



 -- Daniel Taylor  VP OperationsVocal
 Laboratories, Inc.
 dtay...@vocalabs.com mailto:dtay...@vocalabs.com
 http://www.vocalabs.com/ (612)235-5711 tel:%28612%29235-5711



 --
 Daniel Taylor  VP OperationsVocal Laboratories, Inc.
 dtay...@vocalabs.com   http://www.vocalabs.com/(612)235-5711

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

That's not the norm for consumers, but the important thing to understand is
that for most of the technologies we use for broadband there simply is less
upstream capacity than downstream.  That upstream scarcity means that for
DSL, DOCSIS, PON, WiFi, and LTE delivering symmetrical upstream bandwidth
will cost the service provider more which means at some point it will cost
consumers more.

WiFi is a special case, while there is no theoretical reason it must be
asymmetrical but it works that way in practice because dedicated APs
invariably have both higher transmit power and much better antenna gain.
The average AP in the US will put out a watt or more while clients are
putting out ~250 milliwatts and with 0 antenna gain.
On Mar 2, 2015 8:58 AM, Daniel Taylor dtay...@vocalabs.com wrote:

 Personally?
 If the price were the same, I'd go with 50/50.

 That way my uploads would take even less time.

 It isn't about the averaged total, it's about how long each event takes,
 and backing up 4GB of files off-site shouldn't have to take an hour.

 On 02/27/2015 03:11 PM, Scott Helms wrote:

 Daniel,


 50MB/s might be tough to fill, but even at home I can get good use out
 of the odd 25MB/s upstream burst for a few minutes.

 Which would you choose, 50/50 or 75/25?  My point is not that upstream
 speed isn't valuable, but merely that demand for it isn't symmetrical and
 unless the market changes won't be in the near term.  Downstream demand is
 growing, in most markets I can see, much faster than upstream demand.



 Scott Helms
 Vice President of Technology
 ZCorum
 (678) 507-5000
 
 http://twitter.com/kscotthelms
 



 --
 Daniel Taylor  VP OperationsVocal Laboratories, Inc.
 dtay...@vocalabs.com   http://www.vocalabs.com/(612)235-5711

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

That's certainly true and why we watch the trends of usage very closely and
we project those terms into the future knowing that's imperfect.

What we won't do is build networks based purely on guesses.  We certainly
see demand for upstream capacity increasing for residential customers, but
that increase is slower than the increase in downstream demand growth.   In
all cases but pure greenfield situations the cost of deploying DSL or
DOCSIS is significant less than deploying fiber.  Even in greenfield
situations PON, which is a asynchronous itself, is much less expensive than
active Ethernet.

In short synchronous connections cost more to deploy.  Doing so without a
knowing if or when consumers will actually pay for synchronous connections
isn't something we're going to do.

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

Anything based on NNTP would be extremely asymmetric without significant
changes to the protocol or human behavior.

We ran significant Usenet servers with binaries for nearly 20 years and
without for another 5 and the servers' traffic was heavily asymmetric.
On Mar 1, 2015 9:11 AM, Miles Fidelman mfidel...@meetinghouse.net wrote:

 Aled Morris wrote:


 Sadly we don't have many killer applications for symmetric residential
 bandwidth, but that's likely because we don't have the infrastructure to
 incubate these applications.


 Come to think of it, if USENET software wasn't so cumbersome, I kind of
 wonder if today's social network would consist of home servers running
 NNTP - and I expect the traffic would be very symmetric. (For that matter,
 with a few tweaks, the USENET model would be great for groupware -
 anybody remember the Netscape communications server that added private
 newsgroups and authentication to the mix?)

 Miles Fidelman



 --
 In theory, there is no difference between theory and practice.
 In practice, there is.    Yogi Berra

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

Miles,

Usenet was normally asymmetrical between servers, even when server
operators try to seed equally as being fed.  It's a function of how a few
servers are the source original content and how long individual servers
choose (and have the disk) to keep specific content.

It was never designed to have as many server nodes as you're describing and
I'd imagine there's some nasty side effects if we tried get that many
active servers going as we have customers.
On Mar 1, 2015 10:25 AM, Miles Fidelman mfidel...@meetinghouse.net
wrote:

 Scott,

 Asymmetric measured where?  Between client and server or between servers?
 I'm thinking the case where we each have a server running locally - how do
 you get a high level of asymmetry in a P2P environment?

 Miles Fidelman



 Scott Helms wrote:


 Anything based on NNTP would be extremely asymmetric without significant
 changes to the protocol or human behavior.

 We ran significant Usenet servers with binaries for nearly 20 years and
 without for another 5 and the servers' traffic was heavily asymmetric.

 On Mar 1, 2015 9:11 AM, Miles Fidelman mfidel...@meetinghouse.net
 mailto:mfidel...@meetinghouse.net wrote:

 Aled Morris wrote:


 Sadly we don't have many killer applications for symmetric
 residential
 bandwidth, but that's likely because we don't have the
 infrastructure to
 incubate these applications.


 Come to think of it, if USENET software wasn't so cumbersome, I
 kind of wonder if today's social network would consist of home
 servers running NNTP - and I expect the traffic would be very
 symmetric. (For that matter, with a few tweaks, the USENET model
 would be great for groupware - anybody remember the Netscape
 communications server that added private newsgroups and
 authentication to the mix?)

 Miles Fidelman



 -- In theory, there is no difference between theory and practice.
 In practice, there is.    Yogi Berra



 --
 In theory, there is no difference between theory and practice.
 In practice, there is.    Yogi Berra

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

Michael,

Exactly what are you basing that on?  Like I said, none of the MSOs or
vendors involved in the protocol development had any concerns about OTT.
The reason the built QoS was because the networks weren't good enough for
OTT
On Mar 1, 2015 10:51 AM, Michael Thomas m...@mtcc.com wrote:


 On 02/28/2015 06:38 PM, Scott Helms wrote:

 You're off on this.  When PacketCable 1.0 was in development and it's
 early deployment there were no OTT VOIP providers of note.  Vonage at that
 time was trying sell their services to the MSOs and only when that didn't
 work or did they start going directly to consumers via SIP.

 The prioritization mechanisms in PacketCable exist because the thought was
 that they were needed to compete with POTS and that's it and at that time,
 when upstreams were more contended that was probably the case.


 It was both. They wanted to compete with pots *and* they wanted to have
 something
 that nobody else (= oot) could compete with. The entire exercise was
 trying to bring the old
 telco billing model into the cable world, hence all of the DOCSIS QoS,
 RSVP, etc, etc.

 Mike

  On Feb 28, 2015 7:15 PM, Michael Thomas m...@mtcc.com wrote:


 On 02/28/2015 03:35 PM, Clayton Zekelman wrote:

 And for historical reasons.  The forward path started at TV channel 2.
 The return path was shoe horned in to the frequencies below that, which
 limited the amount of available spectrum for return path.

 Originally this didn't matter much because the only thing it was used
 for was set top box communications and occasionally sending video to the
 head end for community channel remote feeds.

 To change the split would require replacement of all the active and
 passive RF equipment in the network.

 Only now with he widespread conversion to digital cable are they able to
 free up enough spectrum to even consider moving the split at some point in
 the future.


 Something else to keep in mind, is that the cable companies wanted to use
 the
 upstream for voice using DOCSIS QoS to create a big advantage over anybody
 else who might want to just do voice over the top.

 There was lots of talk about business advantage, evil home servers, etc,
 etc
 and no care at all about legitimate uses for customer upstream. If they
 wanted
 to shape DOCSIS to have better upstream, all they had to say is JUMP to
 cablelabs
 and the vendors and it would have happened.

 Mike


 Sent from my iPhone

  On Feb 28, 2015, at 6:20 PM, Mike Hammett na...@ics-il.net wrote:

 As I said earlier, there are only so many channels available. Channels
 added to upload are taken away from download. People use upload so
 infrequently it would be gross negligence on the provider's behalf.




 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -

 From: Clayton Zekelman clay...@mnsi.net
 To: Barry Shein b...@world.std.com
 Cc: NANOG nanog@nanog.org
 Sent: Saturday, February 28, 2015 5:14:18 PM
 Subject: Re: Verizon Policy Statement on Net Neutrality

 You do of course realize that the asymmetry in CATV forward path/return
 path existed LONG before residential Internet access over cable networks
 exited?

 Sent from my iPhone

  On Feb 28, 2015, at 5:38 PM, Barry Shein b...@world.std.com wrote:


 Can we stop the disingenuity?

 Asymmetric service was introduced to discourage home users from
 deploying commercial services. As were bandwidth caps.

 One can argue all sorts of other benefits of this but when this
 started that was the problem on the table: How do we forcibly
 distinguish commercial (i.e., more expensive) from non-commercial
 usage?

 Answer: Give them a lot less upload than download bandwidth.

 Originally these asymmetric, typically DSL, links were hundreds of
 kbits upstream, not a lot more than a dial-up line.

 That and NAT thereby making it difficult -- not impossible, the savvy
 were in the noise -- to map domain names to permanent IP addresses.

 That's all this was about.

 It's not about that's all they need, that's all they want, etc.

 Now that bandwidth is growing rapidly and asymmetric is often
 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire
 medium-sized ISPs ran on less than 10mbps symmetric not long ago. But
 it still imposes an upper bound of sorts, along with addressing
 limitations and bandwidth caps.

 That's all this is about.

 The telcos for many decades distinguished business voice service
 from residential service, even for just one phone line, though they
 mostly just winged it and if they declared you were defrauding them by
 using a residential line for a business they might shut you off and/or
 back bill you. Residential was quite a bit cheaper, most importantly
 local unlimited (unmetered) talk was only available on residential
 lines. Business lines were even coded 1MB (one m b) service, one
 metered business (line).

 The history is clear and they've just reinvented the model for
 internet but proactively

Re: Verizon Policy Statement on Net Neutrality

[Scott Helms]

Michael,

Then you understand that having the upstreams and downstreams use the same
frequencies, especially in a flexible manner, would require completely
redesigning every diplex filter, amplifier, fiber node, and tap filters in
the plant.  At the same time we'd have to replace all of the modems, set
top boxes, TV tuners embedded in TV sets, CableCards, and CMTS blades.

We'd also have to change the protocol in significant ways.  Deal with many
more, and more complicated, ingress and egress problems.  We'd also create
FEX and NEX problems that we don't have today.
On Mar 1, 2015 11:04 AM, Michael Thomas m...@mtcc.com wrote:


 On 02/28/2015 06:15 PM, Scott Helms wrote:

 Michael,

 You should really learn how DOCSIS systems work.  What you're trying to
 claim it's not only untrue it is that way for very real technical reasons.


 I'm well aware. I was there.

 Mike

  On Feb 28, 2015 6:27 PM, Michael Thomas m...@mtcc.com wrote:


 On 02/28/2015 03:14 PM, Clayton Zekelman wrote:

 You do of course realize that the asymmetry in CATV forward path/return
 path existed LONG before residential Internet access over cable networks
 exited?


 The cable companies didn't want servers on residential customers
 either, and were
 animated by that. Cable didn't really have much of a return path at all
 at first -- I remember
 the stories of the crappy spectrum they were willing to allocate at
 first, but as I recall
 that was mainly because they hadn't transitioned to digital downstream
 and their analog
 down was pretty precious. Once they made that transition, the animus
 against residential
 servers was pretty much the only excuse -- I'm pretty sure they could
 map up/down/cable
 channels any way they wanted after that.

 Mike


 Sent from my iPhone

  On Feb 28, 2015, at 5:38 PM, Barry Shein b...@world.std.com wrote:


 Can we stop the disingenuity?

 Asymmetric service was introduced to discourage home users from
 deploying commercial services. As were bandwidth caps.

 One can argue all sorts of other benefits of this but when this
 started that was the problem on the table: How do we forcibly
 distinguish commercial (i.e., more expensive) from non-commercial
 usage?

 Answer: Give them a lot less upload than download bandwidth.

 Originally these asymmetric, typically DSL, links were hundreds of
 kbits upstream, not a lot more than a dial-up line.

 That and NAT thereby making it difficult -- not impossible, the savvy
 were in the noise -- to map domain names to permanent IP addresses.

 That's all this was about.

 It's not about that's all they need, that's all they want, etc.

 Now that bandwidth is growing rapidly and asymmetric is often
 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire
 medium-sized ISPs ran on less than 10mbps symmetric not long ago. But
 it still imposes an upper bound of sorts, along with addressing
 limitations and bandwidth caps.

 That's all this is about.

 The telcos for many decades distinguished business voice service
 from residential service, even for just one phone line, though they
 mostly just winged it and if they declared you were defrauding them by
 using a residential line for a business they might shut you off and/or
 back bill you. Residential was quite a bit cheaper, most importantly
 local unlimited (unmetered) talk was only available on residential
 lines. Business lines were even coded 1MB (one m b) service, one
 metered business (line).

 The history is clear and they've just reinvented the model for
 internet but proactively enforced by technology rather than studying
 your usage patterns or whatever they used to do, scan for business ads
 using residential numbers, beyond bandwidth usage analysis.

 And the CATV companies are trying to reinvent CATV pricing for
 internet, turn Netflix (e.g.) into an analogue of HBO and other
 premium CATV services.

 What's so difficult to understand here?

 --
 -Barry Shein

 The World  | b...@theworld.com   |
 http://www.TheWorld.com
 Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR,
 Canada
 Software Tool  Die| Public Access Internet | SINCE 1989
  *oo*