Re: Issues with deliverability to hotmail -- any Microsoft contacts?

[Mark Milhollan]

On Mon, 20 Jul 2020, Brock Tice wrote:


We have been having issues delivering email to [...]


You should probably join the mailop list.


We have repeatedly requested removal of our subnet from their block list
and it has not worked.


You will eventually be conversing with a person if you persist 
responding to the ticket that you opened via the web though initially 
you are not and it might not seem so even after -- do not open multiple 
tickets for the same address/block.



/mark

Re: questions asked during network engineer interview

[Owen DeLong]

> On Jul 21, 2020, at 2:58 PM, Mark Tinka  wrote:
> 
> 
> 
> On 21/Jul/20 22:20, Nick Hilliard wrote:
>  
>> 
>> IOW, it works if you have a large and homogeneous enough network with
>> a sufficiently narrowly product portfolio that you can justify the
>> cost of getting enough programming skill to make the cost/benefit
>> ratio work.
>> 
>> Some networks are like this; many aren't.
>> 
>> In fairness, most networks would benefit from some degree of automation.
> 
> We all could benefit from a sufficient degree of automation, whatever
> that means to you.
> 
> That the cloud bags can throw warm bodies at the problem even more than
> traditional vendors can is an advantage unique to them, even though they
> are not network service providers in the strict sense of the term. This
> is what leads to the divergence in our expectations, to some extent.

That word advantage… I do not think it means what you appear to think it means
in this context. At least not based on some of my experiences with some
of their implementations of certain basic networking features.

Owen

Re: questions asked during network engineer interview

[William Herrin]

On Tue, Jul 21, 2020 at 2:55 PM Mark Tinka  wrote:
> For the avoidance of doubt, "we still don't know what SDN means to us"
> means "we are not sold on the snake oil".

Hi Mark,

I suppose it depends what you're trying to accomplish. If you're a
hosting provider and you want to provide a capability both similar to
AWS VPCs and strong enough to not be a joke, you won't get there on
the tools Linux or VMWare provide. You'll have to invest in SDN tech.
If you're hooking up residential subscribers to the Internet... it's
less obvious how SDN would be of use to you.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 22:20, Nick Hilliard wrote:
 
>
> IOW, it works if you have a large and homogeneous enough network with
> a sufficiently narrowly product portfolio that you can justify the
> cost of getting enough programming skill to make the cost/benefit
> ratio work.
>
> Some networks are like this; many aren't.
>
> In fairness, most networks would benefit from some degree of automation.

We all could benefit from a sufficient degree of automation, whatever
that means to you.

That the cloud bags can throw warm bodies at the problem even more than
traditional vendors can is an advantage unique to them, even though they
are not network service providers in the strict sense of the term. This
is what leads to the divergence in our expectations, to some extent.

Mark.

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 21:21, William Herrin wrote:

> The Software Defined Network concept started as, "Let's use commodity
> hardware running commodity operating systems to form the control plane
> for our network devices." The concept has expanded somewhat to: "Lets
> use commodity hardware running commodity operating systems AS our
> network devices." For example, if you build a high-rate firewall with
> DPDK on Linux, that's now considered SDN since its commodity hardware,
> commodity OS and custom packet handling (DPDK) that skips the OS.
>
> This is happening a lot in the big shops like Amazon that can afford
> to employ software developers to write purpose-built network code.

It's possible that I wasn't clear.

For the avoidance of doubt, "we still don't know what SDN means to us"
means "we are not sold on the snake oil".

Mark.

Re: questions asked during network engineer interview

[Robert Raszuk]

Bill,

> The Software Defined Network concept started as, "Let's use commodity
> hardware running commodity operating systems to form the control plane
> for our network devices."

That's not exactly the real beginning ... the above is more like oh where
do we plug this SDN into and how do we sell it :)

The last churn of SDN as I recall and as explained by Nick McKeown was an
attempt to open innovation into networking ... allowing one to invent
protocols at will as well as setup forwarding tables with arbitrary
switching/routing capabilities as student or operator would only like to
imagine.

That's when the OF was born (with various versions of it) to allow the
hardware and software decoupling.

Well I guess that experiment can be considered as completed today :)

Best,
R.


On Tue, Jul 21, 2020 at 9:22 PM William Herrin  wrote:

> On Mon, Jul 20, 2020 at 9:57 PM Mark Tinka  wrote:
> > Suffice it to say, to this day, we still don't know what SDN means to
> > us, hehe.
>
> Hi Mark,
>
> The Software Defined Network concept started as, "Let's use commodity
> hardware running commodity operating systems to form the control plane
> for our network devices." The concept has expanded somewhat to: "Lets
> use commodity hardware running commodity operating systems AS our
> network devices." For example, if you build a high-rate firewall with
> DPDK on Linux, that's now considered SDN since its commodity hardware,
> commodity OS and custom packet handling (DPDK) that skips the OS.
>
> This is happening a lot in the big shops like Amazon that can afford
> to employ software developers to write purpose-built network code.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Issues with deliverability to hotmail -- any Microsoft contacts?

[Brock Tice]

Many times. I get a weird auto-response after a couple days that doesn't
make any sense and then nothing else happens.

On Mon, Jul 20, 2020 at 1:51 PM Tony Wicks  wrote:

> Have you used this form? I feel your pain.
>
>
>
>
> https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75
>
>
>
> *From:* NANOG  *On Behalf Of *Brock
> Tice
> *Sent:* Tuesday, 21 July 2020 4:11 am
> *To:* nanog@nanog.org
> *Subject:* Issues with deliverability to hotmail -- any Microsoft
> contacts?
>
>
>
> We have been having issues delivering email to hotmail users again, no
> bulk mail, just various personal emails from a server on our network. We
> have signed up for SNDS, only identified one mail server of a customer on
> our network that was flagged as an issue, and it has been remedied, no
> longer showing in SNDS.
>
> We have repeatedly requested removal of our subnet from their block list
> and it has not worked. MS has done a great job of making it impossible to
> contact anyone about this. Does anyone have pointers on what else can be
> done or whom we should contact to get this resolved?
>
>
>
> Thanks,
>
>   --Brock
>
>
>
> --
>
> Brock M. Tice
>
> Co-Owner and President
>
> Black Mesa Wireless LLC
>
> 505-852-5101
>
> br...@bmwl.co
>


-- 
Brock M. Tice
Co-Owner and President
Black Mesa Wireless LLC
505-852-5101
br...@bmwl.co

Re: questions asked during network engineer interview

[Mel Beckman]

Nick,

SDN works very well even for tiny networks. Look at Ubiquiti’s SDN controller. 
Yes, it requires proprietary hardware (proving SDN isn’t only for commodity 
hardware). But it can scale a network of a single switch up to hundreds of 
switches with a single point of configuration. You want a new VLAN across the 
entire network? It’s a couple clicks. Want to deploy an new SSID in one 
department? A few more clicks. It’s very well designed for small- and mid-sized 
networks. 

Bigger networks use other products. But there is an SDN solution off-the-shelf 
today for every size. 

-mel via cell

> On Jul 21, 2020, at 1:22 PM, Nick Hilliard  wrote:
> 
> William Herrin wrote on 21/07/2020 20:21:
>> This is happening a lot in the big shops like Amazon that can afford
>> to employ software developers to write purpose-built network code.
> 
> IOW, it works if you have a large and homogeneous enough network with a 
> sufficiently narrowly product portfolio that you can justify the cost of 
> getting enough programming skill to make the cost/benefit ratio work.
> 
> Some networks are like this; many aren't.
> 
> In fairness, most networks would benefit from some degree of automation.
> 
> Nick
> 

Re: questions asked during network engineer interview

[Mel Beckman]

Brandon,

The problem is your door is stuck in 2014 :)

A lot has happened in the last six years. 

-mel via cell

> On Jul 21, 2020, at 10:26 AM, "adamv0...@netconsultings.com" 
>  wrote:
> 
> 
>> 
>> From: Mark Tinka 
>> Sent: Tuesday, July 21, 2020 6:14 PM
>> 
>>> On 21/Jul/20 18:39, adamv0...@netconsultings.com wrote:
>>> Little you two know about SDN, please read the following presentation
>> from Scott Shenker and then get back here arguing what it is and what it is
>> not: https://inst.eecs.berkeley.edu/~cs168/fa14/lectures/lec23-public.pdf
>> 
>> I'll pass, thanks. Already did my time in that rabbit hole.
>> 
> Well  "I can only show you the door. You're the one that has to walk through 
> it."  ;)
> 
> adam
> 

Re: questions asked during network engineer interview

[Nick Hilliard]

William Herrin wrote on 21/07/2020 20:21:

This is happening a lot in the big shops like Amazon that can afford
to employ software developers to write purpose-built network code.


IOW, it works if you have a large and homogeneous enough network with a 
sufficiently narrowly product portfolio that you can justify the cost of 
getting enough programming skill to make the cost/benefit ratio work.


Some networks are like this; many aren't.

In fairness, most networks would benefit from some degree of automation.

Nick

Re: questions asked during network engineer interview

[William Herrin]

On Mon, Jul 20, 2020 at 9:57 PM Mark Tinka  wrote:
> Suffice it to say, to this day, we still don't know what SDN means to
> us, hehe.

Hi Mark,

The Software Defined Network concept started as, "Let's use commodity
hardware running commodity operating systems to form the control plane
for our network devices." The concept has expanded somewhat to: "Lets
use commodity hardware running commodity operating systems AS our
network devices." For example, if you build a high-rate firewall with
DPDK on Linux, that's now considered SDN since its commodity hardware,
commodity OS and custom packet handling (DPDK) that skips the OS.

This is happening a lot in the big shops like Amazon that can afford
to employ software developers to write purpose-built network code.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 19:26, adamv0...@netconsultings.com wrote:

> Well  "I can only show you the door. You're the one that has to walk through 
> it."  ;)

You misunderstand me, Adam. I am not averse to learning new things.

What I am saying is I've spent 10 years on this road, and the summaries
you see me providing on this list are the most simplified conclusions
that are informed by a decade of this dance.

Seeing the bigger picture is, many times, as important as seeing the
detail. I don't expect you (or many) to share my point of view. And
that's okay, as long as we keep the Internet running.

Mark.

Re: questions asked during network engineer interview

[Brandon Martin]

On 7/21/20 12:55 AM, Mark Tinka wrote:

Suffice it to say, to this day, we still don't know what SDN means to
us, hehe.


I think that's part of the problem.  It means too many different things 
to different people.  Much of what people refer to SDN is useful, albeit 
often pre-existing before the SDN craze...you just have to know what it is.


Reminds me of the early days of ".NET" at Microsoft.  Everything was 
".NET", and eventually it became an actual thing.

--
Brandon Martin

RE: questions asked during network engineer interview

[adamv0025]

> From: Mark Tinka 
> Sent: Tuesday, July 21, 2020 6:14 PM
> 
> On 21/Jul/20 18:39, adamv0...@netconsultings.com wrote:
> > Little you two know about SDN, please read the following presentation
> from Scott Shenker and then get back here arguing what it is and what it is
> not: https://inst.eecs.berkeley.edu/~cs168/fa14/lectures/lec23-public.pdf
> 
> I'll pass, thanks. Already did my time in that rabbit hole.
> 
Well  "I can only show you the door. You're the one that has to walk through 
it."  ;)

adam

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 18:39, adamv0...@netconsultings.com wrote:
> Little you two know about SDN, please read the following presentation from 
> Scott Shenker and then get back here arguing what it is and what it is not: 
> https://inst.eecs.berkeley.edu/~cs168/fa14/lectures/lec23-public.pdf

I'll pass, thanks. Already did my time in that rabbit hole.

Mark.

RE: questions asked during network engineer interview

[adamv0025]

> William Herrin
> Sent: Monday, July 20, 2020 9:02 PM
>
> On Mon, Jul 20, 2020 at 5:09 AM Mark Tinka 
> wrote:
> > We'll probably spend 95% of the time just talking about who they are,
> > and 5% on the role. That has worked well for me in the past decade,
> > and none of those hires had any "certificates" to impress me with,
> > even though those that didn't make it, did.
> 
> I find there's a strong INVERSE correlation between the quantity of
> certificates on an applicant's resume and their ability to do the job.
>
One can't be an expert in many areas, (like CCIE-everything... folks)
Same as Usain Bolt can't swim like Michael Phelps...
 

> I still have to laugh about the guy who let me know via his resume that he
> was certified in setting up Kentrox CSU/DSUs.
> 
Nice, did he also knew how to put a loop on a T1/T3 DACS (DCX) or how to do SNA 
to mainframe and then DLSW? :) very useful skills these days indeed. 
technology used to be much simpler. 


adam

RE: questions asked during network engineer interview

[adamv0025]

Little you two know about SDN, please read the following presentation from 
Scott Shenker and then get back here arguing what it is and what it is not: 
https://inst.eecs.berkeley.edu/~cs168/fa14/lectures/lec23-public.pdf

adam

Re: questions asked during network engineer interview

[Ben Cannon]

I come from the “we’ve had SDN for years, it’s called L2VPN” but I guess the 
rest of the world hasn’t been a carrier for 26yrs either.
-Ben

Ms. 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 Jul 20, 2020, at 9:55 PM, Mark Tinka  wrote:
> 
> 
> 
> On 20/Jul/20 23:59, Brandon Martin wrote:
> 
>> Pass given to those who cram them into a "certificates" or "specifics"
>> line or similar in order to get around HR filters, limit them to major
>> certs (or ones your HR dept. specifically demanded), and don't really
>> mention them otherwise.  Bear in mind as well that, even if your
>> hiring process doesn't demand them, others' will, and many people have
>> a standard-ish resume with application-specific cover letter.
> 
> When SDN was all the rage in the middle of the past decade, our HR
> department wanted to hire someone in this field and asked me what type
> of qualifications and certifications they should be looking for. Well, I
> told them to look for someone who had enough will and time to figure out
> what it means to us, and the patience to experiment, fail and experiment
> again, without losing any steam or confidence, and take a pass on any
> SDN certifications recommended by our "recruiting consultants".
> 
> We ended up hiring a regular (but very good) network engineer who had
> recently taken up an interest in understanding and writing software to
> perform repetitive tasks. It was just a shame they chose not join at the
> last minute, but we weren't the worse off for it either.
> 
> At the time, everyone and their arm rest were offering some kind of
> SDN-workshop-certification thingy.
> 
> Suffice it to say, to this day, we still don't know what SDN means to
> us, hehe.
> 
> Mark.
> 

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 17:43, Mel Beckman wrote:
> Have any of those operators shipped an SDM product? If not, then of
> course, they are pre-SDN. Just like NASA is pre-commercial space
> launch :-)

It never occurred to me that SDN was the service provider product. Dang,
we've been doing it all wrong :-).

Mark.

Re: questions asked during network engineer interview

[Mel Beckman]

Have any of those operators shipped an SDM product? If not, then of course, 
they are pre-SDN. Just like NASA is pre-commercial space launch :-)

-mel via cell

On Jul 21, 2020, at 8:17 AM, Mark Tinka  wrote:



On 21/Jul/20 16:59, Mel Beckman wrote:


But SDN is NOT just ""SDN = some kind of automation””. Its centralized 
management with good automation built-in. Good automation means automation that 
orchestrates cohesive, correct network changes — and can roll them back — not 
just scripts that can spew configs into individual devices.

So operators who've been doing this for decades are, what? Pre-SDN :-).


And you say SDN consists of "bits of code and ideas coming out of these 
operators” as if that’s a bad thing. That’s how all innovation happens in IT.

I didn't say it was a bad thing; I said the gap to standardization will remain 
wide if we are not feeding off the full story.



Today's SDN has delivered on orchestration and good automation.You only have to 
shop and compare, the products are there and very powerful.

Oh, don't get me wrong - we've seen all the products. Evaluated a bunch. Not 
enough for me to write a cheque though; many of the vendors can't make their 
own minds up. But meh, YMMV.



But more germane to this discussion, I would expect any network engineer 
candidate to know all about SDN, know how various vendors implement it, and 
have experience using it.

You wouldn’t expect a bridge engineer to not be proficient in advanced 
computational modeling, would you? Or an electrical engineer to not understand 
field-programmable gate arrays? Or a chemical engineer ignorant of SCADA 
programmable logic controllers?

That’s the equivalent of an SDN-ignorant engineer in today’s market.

Well then show me the door to where the SDN-ignorants are gathering. I'll go 
join them for a laugh :-).

Seriously though, I'm not dismissing "SDN". I'm just saying we may not all 
agree on what it means for us. So let's spend more time on what we can agree 
on; how folk get there (SDN, or whatever name we dream up this decade) is up to 
them.

If we still struggle to implement a basic, but standard BCP-38/MANRS on a 
global scale, I think we may be shooting for the stars to standardize that 
other thing.

Mark.

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 16:59, Mel Beckman wrote:

>
> But SDN is NOT just ""SDN = some kind of automation””. Its centralized
> management with /good /automation built-in. Good automation means
> automation that orchestrates cohesive, correct network changes — and
> can roll them back — not just scripts that can spew configs into
> individual devices.

So operators who've been doing this for decades are, what? Pre-SDN :-).


> And you say SDN consists of "bits of code and ideas coming out of
> these operators” as if that’s a bad thing. That’s how all innovation
> happens in IT.

I didn't say it was a bad thing; I said the gap to standardization will
remain wide if we are not feeding off the full story.


>
> Today's SDN has delivered on orchestration and good automation.You
> only have to shop and compare, the products are there and very powerful.

Oh, don't get me wrong - we've seen all the products. Evaluated a bunch.
Not enough for me to write a cheque though; many of the vendors can't
make their own minds up. But meh, YMMV.


>
> But more germane to this discussion, I would expect any network
> engineer candidate to know all about SDN, know how various vendors
> implement it, and have experience using it.
>
> You wouldn’t expect a bridge engineer to not be proficient in advanced
> computational modeling, would you? Or an electrical engineer to not
> understand field-programmable gate arrays? Or a chemical engineer
> ignorant of SCADA programmable logic controllers? 
>
> That’s the equivalent of an SDN-ignorant engineer in today’s market.

Well then show me the door to where the SDN-ignorants are gathering.
I'll go join them for a laugh :-).

Seriously though, I'm not dismissing "SDN". I'm just saying we may not
all agree on what it means for us. So let's spend more time on what we
can agree on; how folk get there (SDN, or whatever name we dream up this
decade) is up to them.

If we still struggle to implement a basic, but standard BCP-38/MANRS on
a global scale, I think we may be shooting for the stars to standardize
that other thing.

Mark.

Re: questions asked during network engineer interview

[Mel Beckman]

Mark,

But SDN is NOT just ""SDN = some kind of automation””. Its centralized 
management with good automation built-in. Good automation means automation that 
orchestrates cohesive, correct network changes — and can roll them back — not 
just scripts that can spew configs into individual devices. And you say SDN 
consists of "bits of code and ideas coming out of these operators” as if that’s 
a bad thing. That’s how all innovation happens in IT.

Today's SDN has delivered on orchestration and good automation.You only have to 
shop and compare, the products are there and very powerful.

But more germane to this discussion, I would expect any network engineer 
candidate to know all about SDN, know how various vendors implement it, and 
have experience using it.

You wouldn’t expect a bridge engineer to not be proficient in advanced 
computational modeling, would you? Or an electrical engineer to not understand 
field-programmable gate arrays? Or a chemical engineer ignorant of SCADA 
programmable logic controllers?

That’s the equivalent of an SDN-ignorant engineer in today’s market.

 -mel

On Jul 20, 2020, at 10:34 PM, Mark Tinka 
mailto:mark.ti...@seacom.com>> wrote:



On 21/Jul/20 07:12, Mel Beckman wrote:
Mark,

There are a slew of fine SDN products out there, from VMware NSX-T in big 
enterprise to Ubiquiti UniFiOS in SMBs, and lots of other products aimed at 
various market niches. What failed about the original SDN academic vision, more 
or less, was standardized, vendor-agnostic SDN based on protocols such as 
OpenFlow. Sure, a standardized platform would be nice, but you can’t blame 
vendors for wanting to differentiate their products to gain marketshare. 
OpenFlow never really delivered in a way that any vendors could build a 
competitive product around. HP tried, but, well, here we are.

The goal SDN was created for was centralized management with good automation 
built in. Nobody ever promised single-pane management of multiple vendors’ 
network elements. Nobody promised that because there is no way to make a living 
selling that.

And despite taking the long route to get to that conclusion, that is
essentially what we've had to learn the hard way.

If "SDN = some kind of automation", this isn't new. Operators abound
have been "automating" for years... decades, even. It's just that their
solutions have been internal, either entirely homegrown, or cobbled
together with hand-written + external vendor-provided systems. These
systems have grown and become significantly large to the extent that it
makes it difficult for these "established" operators to want to
participate in "standardizing" what they already have, or openly
contribute to a standardization process because, well, they don't really
have a problem to solve.

Moreover, a lot of the drive on these "SDN thingies" is bits of code and
ideas coming out of these operators (notably, the cloud bags [boys &
girls]), when they are feeling generous to share what they've been
working on with the community. Regardless of what they share, they are
probably 10 years ahead of what we get to see. How do you expect to
standardize a gap like that?

Ultimately, I don't think the industry will reasonably agree on
standardization of this process. 40 years of the Internet and you still
can't "buy" an NMS that "just works". That should tell you something :-).

We should be spending more time encouraging folk on how to simplify
repetitive tasks. The actual solutions they decide to implement to get
there should be left to them. I don't want to waste another decade on this.

Last week's Cloudflare incident should remind us how uncomplicated this
is. The problems we need to solve are as simple now as they were 25
years ago. So let's not complicate it anymore than we need to.

Mark.

Re: questions asked during network engineer interview

[Nathan Stratton]

On Mon, Jul 20, 2020 at 4:45 PM Sander Steffann  wrote:

> > I find there's a strong INVERSE correlation between the quantity of
> > certificates on an applicant's resume and their ability to do the
> > job.
>
> Never got a certificate, don't want one either :)
>

That's what I said about high school, my parents were not thrilled, but at
least for me, it worked out.

-Nathan