Join us as we gather around the hedge,
where we dig into technology,
business, and culture with the finest minds in
computer networking.
Well, hello, Tom. How are you? Hey, Russ.
I'm doing great. Good.
How about you?
I'm okay.
Things are up and down the last couple
of weeks, but, you know so,
are you turning the plant so it gets
evenly roasted?
No. I should, though. That's a good idea.
Yeah. I mean, you know, you wouldn't wanna
eat a plant that's
a raw side and a cooked side. You
you really should. I'm glad that you are
saying this while I have my headphones on
so the plant can't hear you, talking about
eating it because I'm pretty sure the plant
would be offended.
But then I just said If I if
I say it louder yeah. I was gonna
say if I say it louder, I can
make you repeat it and then the plant
will hear either way.
We're eating you plant. Okay. Alright. And today,
we are joined by Mark. Mark, I don't
remember your last name. The Prosser.
Mark Prosser. There we go.
Oh my goodness.
My my mind is like a steel sieve,
only the big chunks stick.
That's what I feel like. It was like
my mind is a steel trap. Yeah. My
mind's a steel trap with holes.
It's okay. It's a regular name. You can
say it once and never say it again.
So, Mark, where are you physically located?
I'm here in Toronto, Ontario, Canada. Okay.
Interesting. We've been watching Murdoch. Now according to
the Murdoch Mysteries,
everything that is of any value in the
modern life
was invented in Toronto by Murdoch.
Okay. I don't know if you ever watched
the mysteries, but that's pretty much the way
it runs. Oh, we invented a way to
wire up a
a bag of money in a bank so
it explodes with dye.
Oh, well, we invented a way to it's
like, by the fifteenth show, you know, he's
like showing Nikola Tesla around
some new electric electronic thing he's invented.
You know, like, yeah. I think I think
the trope might be getting old.
Just just
Yeah. I think that, Hawaiian pizza was invented
on the West Coast Of Canada. So, yeah,
maybe everything in useful to society was invented
here in Toronto.
Yeah. It's that's a possibility.
So we're talking about
CLIs today, which command line interfaces.
Now, you know, for those of you who
are older in the networking world,
that's what we had.
And
I'll I'll say this. It's an interesting point
that people don't
I don't think people understand very well or
or comprehend or or,
glom onto
is that one of the big innovations
of Cisco c of Cisco iOS software
classic
was
the verb,
the verb noun
sort of grammar
in the CLI.
They did it very poorly in many ways.
But before
Cisco,
CLI's were much more information dump
and much less take action on this with
that.
And so I think that's one reason
why the Cisco CLI in particular
really took off
and became something that people
used.
So I don't know if you have any
thoughts on that before we
Yeah. I mean, like, when you compare it
to even systems that are still around, if
you look at, like, the the lens shell
or the bash shells, edge shell, anything like
that,
I still Google how to
extract and compress a tar file today. It's
not so intuitive. As I spoke to it,
it's like it's like,
compress this file with this compression would probably
how it'd be done on Cisco CLI.
But in that file, it's just a bunch
of flags, Right? That add on. Right? And
do I have the right flags? Now that
I probably do the same file over and
over. Yes. But if I have to change
one of those flags, it's not intuitive at
all for me. And it's very information dump
when you look at that man file. Yeah.
Exactly.
The the things are not ordered
in any kind of order or grouping,
whereas with Cisco CLI, they are. And I
think that's I think that was one of
the big revolutions
of the Cisco CLI.
Tom, any thoughts on that before we carry
on to the next little?
No. I think the the structure of a
CLI
is pretty pretty critical. I mean, it's it's
a it's a user interface. I think that's
the thing we when we think of a
user interface, I think often we think of,
like a GUI, like something a web page
you would click on. But the reality is
a CLI is a user interface,
and it's not a machine interface. And so
it's, you know, it needs to be designed
with user experience in mind. It needs to
be something that the human brain would would
find,
as as natural,
in order for it to be effective. It's
not in in some ways, the design of
the CLI
is even more critical than the what we
would call user experience on a web GUI,
because there's the user experience is the only
thing
to that that is even that's the purpose
of the CLI existing.
Yeah. And I think a lot of the
design differential between good CLI and bad CLI
is that bad CLI
always caters to the data structures
and the the,
underlying
function calls.
Whereas good CLI
says, what is the user trying to get
done?
Right.
Yeah. Exactly. I mean, you could see it
in some CLI tools where, like, those new
functions or new features to kind of leak
into the CLI as, like, leaky abstractions. So
they they put a new flag, right, for
the new feature, or they can put the
rework the CLI. There's no flow to it.
Correct. And like I said, Cisco
has messed up, in my opinion, the verb
to noun interaction in many places,
but they at least have the construction there
to start with that they've tried to do
something with.
There are many annoying examples to me.
IP routing, let's see. What was it?
For turning on
fast cache,
I believe it was IP routing cache or
something like
that or IP cache. And then for SaaS,
it SaaS, it was Cisco Express forwarding IP.
And, like, yeah, it's
why? Why do you do such things?
But, anyway alright. So Mark has been doing
a little bit of ad hoc research, perhaps,
gathering impressions and communities. Why don't you tell
us about that, Mark?
Yeah. So, as I've been working more so
in my day job, I've switched to working
on more network automation
and thinking about how systems should be utilized,
how to get the value out of them,
how to represent them to users.
And one thing that was my hypothesis that
the CLI is very important to network engineers
and we should have a CLI
represented in that system.
But as I started speaking with some colleagues
in my network automation space, they basically said
the goal is to get rid of the
CLI in certain senses. It's to represent that
via
GUIs and and other APIs. And the CLI
should be kind of an afterthought. Right? But
CLI should just exist on the systems as
it is if we don't take it away
altogether.
So then I I set it the poll
to multiple communities. One in the Packet Pusher
Slack community, another in the Nanon mailing list,
and another one in the network automation forum.
And
when I put that to the communities, I
found that there was a little more consensus
than I expected. People do like the CLI.
It's just more about the trade offs as
usual when you try to keep it around
in its current form, as well as when
you try to abstract away via GUI.
I think the,
the idea that we would that we would
remove a CLI is interesting or that we
would that we would not,
let it advance with, features that get added
to the underlying code. I think that's,
that's very interesting. I'm not sure,
Yeah. That would be interesting to see what
people think we get out of that,
other than, like,
maybe some saving some development time in the
product.
But, like, the
the idea that we wouldn't have a seal,
I just there's there's too much
too much that can go wrong. There's too
many variables. These systems are so complex.
How would how would you
like, my experience with network automation is is
finding patterns, finding repeatable things,
that you then automate.
You don't you don't
the thing the things that are not repeatable
patterns, you have to be able to deal
with reality,
without having mocked it up in a lab
first. So the idea of no CLI is
very interesting. Seems counter to my thinking.
Yeah. I mean, I concur. I mean, I
think it's all about the patterns. And when
we think about
we know it's really about patterns because there's
those pipe include pipe match, you know, those
looking and trying to parse out those patterns
and, therefore, you try to abstract that away.
It's more about what are those patterns and
why the best way to get them out
of the system. I guess maybe the problem
also comes back that some of the things
we can get from the CLI is looking
at the system as a whole. Like you're
reading TLVs from the ISAS,
IGP.
But when you look at some things that
are like maybe local databases like interface stats
or, you know, labels in the case of
LDP and such like that, like, we maybe
those things need to be
stored in another system that could be read
from a CLI interface is kind of the
the thinking I've moved to towards now. But,
yeah, people do like the CLI because it
can run on the toaster. It has out
of band access.
It's easy to add new features into it,
and it doesn't add a bunch of security
vulnerabilities as well. By creating all these GUIs,
it's harder to run it on maybe two
different browser engines that exist in the world
and Java on the system just to be
able to get the same data from what
you can get from a a serial interface.
Do you think it's ever possible
well well, first of all, I should back
up. So you polled various communities. What was
the result?
I think the the consensus that I wasn't
expecting because I left it open. Like, do
you love the CLI? Do you hate the
CLI? And do you think we could ever
get to a world or would you argue
already enjoy a world where you never see
or touch the CLI
in a network engineering sense. And the consensus
was nobody imagined a world that the CLI
would go away. It's always for it's what
Tom said, those corner cases. All, like, the
little features of what you're looking for, maybe
they don't exist in the CLI. Whether it's
attack command or not, it's typically there. It's
probably the most complete representation
of the underlying function calls, the API, and
etcetera.
Well, and it's always I mean, the CLI
is always going to be there because there
are developers working on these systems that need
to debug them. Like, you're not gonna convince
any vendor to get rid of the CLI.
I don't like, why would you why like,
that's their debugging tool. Right? It seems,
I don't know.
So so one thing I think that we
run into, we don't maybe don't put it
in these terms, is richness.
Even on the output side,
I think that the CLI output
tends to be richer
than any GUI output you can ever come
up with. I I Yeah. I mean
Yeah. I mean, there are there are times
where you can do a graph. Right? And
that's gonna be richer than what you can
display in a strict CLI.
It's not a lot.
Most of the time, the CLI is gonna
be richer.
Yeah. And then the richness, the price that
you pay from the development standpoint of the
development of the product, the price that you
pay for delivering that richness is much lower
in the CLI. You don't have to do
JavaScript and Ajax, blah blah blah, and all
this crap. Like, if you want to display
a rich you wanna dump a data structure,
it's pretty easy to do that, and it's
pretty easy to build it so that it
can do that in the CLI.
And and humans can as long as the
output format in the CLI is something that
makes sense that, again, going back to our
UI design kind of
conversation,
as long as it's done that way, you
can get a lot more bang for your
buck in terms of development of the product.
Yeah. I mean, like, it's doing front end
design for for websites is is quite a
craft. And to add that complexity on top
of the data that we're trying to represent,
it's very noisy. Like, I don't think there's
any comparison between control f or, like, find
in page on a website versus, like, the
complex
GREP and, regex patterns we can do in
the CLI. Like, we can really take the
noise out of what is a large expression
and the richness in that verbose command or
extensive command or whatever it is based on
the CLI or DSL you're referring to.
So another
I think I think part of that ranges
too though is not just on the receiving
outbound side but also on the inbound side.
Being able to configure things.
The first time I saw Cisco Cisco's iOS
CLI
in a web page, I was
really underwhelmed,
really underwhelmed.
Like, it was far harder to configure things
in that environment than it was just to
use a CLI.
So I think that there's a lot of
richness again that you that you lose,
going from one to the other, from going
from a CLI to a g GUI or
whatever it happens to be. So, I mean,
I guess
that's the biggest thing to me. Now one
thing, Mark, is you said you asked three
different communities. Was there a difference
in the results?
Yeah. I I would say that there was.
I mean, the first response,
and I'll never forget it from the Nanog
mailing list was you'll pry it from my
cold dead hands. Right? That's kind of what
I expected,
from that community.
But
what came after was how each community kind
of differentiated
what it is that they love about the
CLI or what they would like to replicate
in another system from the CLI.
In in the network automation forum, it was
really about getting those corner cases, getting those
patterns represented, which is a hard fact to
do to get that 100% completion.
In the
in the, NANOG mailing list is more about
the reliability
of the CLI, the the familiarity, the intuitiveness
for a lot of these systems that people
grew up on.
And in the packet pushers, it was a
mix of both. Right? So I guess they're
more of the hybrid environment. We have a
little bit of this side and a little
bit of that side.
So there was that difference, but
it wasn't a huge difference. They both considered,
like, the the trade offs, the advantages.
Right? They just disagree on what what is
the most important one. So they all generally
agreed that they said, basically, you'll get rid
of it when you pry it from my
gold cold dead hands.
But they were for different reasons. Some people
were very strongly about,
like you said, like,
speed or whatever, which by the way speed
is another big one to me. CLIs are
a lot always a lot faster. I can't
imagine
ever having a GUI that's faster than a
CLI.
Now I say that, but, you know, now
when you talk about writing,
like, just writing,
people go, oh, well, I would rather use
markup or I would rather use something else.
I'd rather not
use word or something that is menu driven.
And I actually find it a little bit
the opposite. And I'll tell you why, because
I
don't want to memorize
yet another markup language
for writing Word documents or just generic documents.
And it's very easy when you start with
one to end up needing to memorize,
oh, there's markup over here, but then there's
the specialized version of markup over there. And,
oh, by the way, there's this XML thing
over here that you should use. Oh, and
there's a different one over there. It's like
it's so easy to write CLIs
that we have
way more of them.
And so there's some
counter to that in my mind where I'm
doing things where they have a lot of
text,
and I don't have a lot of rich
formatting
or a lot of rich data
where this where the GUI actually makes more
sense to me.
It's a I think you hit you hit
a really interesting point.
What I didn't ask the community and I
didn't do a follow-up on, which I would
love to do at some time, is that
everybody says you love the CLI and you
hate the GUI. Some of them say maybe
I prefer a GUI for certain things, and
I hate the CLI.
But if you go deeper and think this
back to, like, people who use text editors
for code, maybe everybody uses Vim and everybody
use Emacs, both agree that bloated IDs suck
in their opinion. But ask them to get
along in the same room. It's like if
they if they eliminated
that enemy, do they agree on what the
structure and pattern should be within their text
editors, their terminal based text editors? No. They
would say the patterns aren't the same. So
the people who talk about these domain specific
languages or CLIs, they might actually
infight when you get to what is the
best way to represent these patterns. Like, people
who are really into Juniper syntax, people who
are really into, I guess, Cumulus syntax in
the past, and,
maybe CLI classic iOS versus IOS XR. I'm
very much in the iOS XR camp. I
like the the patterns and expressions that that
gives for me.
So it's it's that. So, yes, it's so
people basically say, I just want similar patterns.
And for me, I agree with you. I
think that CLI
is my way of exploring the patterns
and the system, and it's I find it's
intuitive. I can learn a lot about the
system
quickly on the CLI, especially during an incident.
And then maybe I go to something like
the API
for
the final product later on, like and that
would be equivalent to, like, LaTeX. I write
the document or the idea and the drafts
in plain text. And I would go to,
like, something for typesetting
or formatting
later after the exploratory portion of the writing
is done. Yeah. So one way I would
express that is to me,
is that if I'm in an information rich
environment,
but I understand
how the system works,
I might not know how it's implemented.
This implementation
of that software works, but I understand how
the software itself works.
And, again, very inter information rich environment.
I find CLIs are easier to explore,
to traverse the space, and to query and
ask questions
to find what I'm looking for. Whereas GUIs
tend to be
it's in that menu someplace
because somebody thought that's where it should be,
and it's hard to discover.
So discovery in information mission environment is
easier with a CLI. Now, you know, go
back to forward processing and coding.
I mean, in reality,
a lot of the argument I think gets
so heated specifically because and people are gonna,
like,
be mad at me for saying this, but
because it's not an is information rich of
an environment
in many ways.
Unless you've built
the code
syntax, the language syntax into
the IDE
or into the,
into the the the text editor.
There's not, I mean, there's not a lot
of richness
in in those types of things. And so
most of the richness comes from building those
things into
the building that the constructs into
the CLI itself,
or into the programming environment, the IDE or
whatever it is you're using,
and then finding clever ways to call that
syntax up more quickly
than you as a coder remembering it
and putting it in.
And so, you know,
VIM does some things very quickly.
Emacs does other things very quickly.
A lot of the quickness is in search
and replace.
And in mass text moves. I've gotta move
every I created a new function, and I've
gotta grab everything and move it to the
right
by one tab or by four spaces or
whatever your style is.
Those are very specialized operations.
So I don't know. I mean, it just
seems to me again, a lot of this
comes down to the richness of
the
the the implementations,
the protocols,
the
the datasets that you're working with. Yeah. If
you come back to ISAS, I mean, I
agree with you. I could go to a
new
CLI.
And as long as I know
what pattern or TLV I'm looking for,
Doesn't matter how large how large in scale
it is, how you've kind of designed a
little bit here, as long as I know
where to find
that particular element of the network, like who
advertises prefix to me or this TLV with
a prefix attached to it. I can look
for that.
Whereas in a GUI, it's it's kind of
a predetermined query. Right? It's the query language
kind of the art of the query language
goes away. I might be able to search
that. I might not be able to search
that. But in the CLI, I can define
that query to match what I know of
the system or how the system
should be implemented.
So I'm curious, Mark, what is what is
your favorite CLI, if you don't mind saying
which which vendor or which experience would you
say is the one that you're like, yeah.
If they could all be like this. You
mentioned iOSXR before.
What what do you think is your your
favorite? I think yeah. It
it really depends on, I guess, like,
the environments I've worked in in the past.
But I think my favorite, my little favorite
pet is iOSXR.
I'm most used to its patterns. I've worked
with it over many years.
I'm most familiar with it. Classic iOS,
I like some of the simplicity from it.
And and with the Juno CLI, that's kind
of transformed over the years.
I like some of the verbose elements from
that. Right? Like, when I type extensive, I
know what I expect from there. If I
type terse, I know what I expect from
there. It depends on what operation I'm doing
at what time. But I was six are
in the argument of pets versus cattle. It's
my favorite pet in that regard.
And, actually, I think that leads to another
thing that I think comes up in CLI
discussions,
and programmability.
I I one model that that I think
is is a great way to approach this
is the the CLI actually doesn't have to
be
so you you're you're gonna have to have
some sort of programmatic interface. I mean, that's
pretty obvious. And and, really, the CLI should
use the same should use the same APIs
that everybody else is using to program the
box. Right? Like, ideally, you'd have a CLI
that is just a client application,
and
the,
you know, the programmatic inter to the to
the regular programmatic interface. One of the things
that drives me crazy the most is when
there's not parity
between either for monitoring or for configuration between
a CLI and what you get in out
of the API or the programmatic interface.
Yeah. I I concur completely. I mean, that
actually came up in the NANOG mailing list,
right, about how it's
maybe representing the lower layers. And in some
environments,
there is a pretty good parity. And in
some environments, it's very apparent that there isn't.
Yeah. So I don't wanna name any vendor
specifically, but you can go read in the
mail list and see which vendors are being
mentioned on the good side and bad side.
Some have a back end database everybody draws
from, some do not.
And some and some are in the middle,
honestly.
Let's be honest. I mean, if our routing,
for instance, some of it has been
yangified as we might say, and other parts
have not been.
And so it's inconsistent
across the different protocols,
which is maddening as an operator. But, you
know, it's it's a coding problem. Somebody's gotta
go code it.
And, you know,
it's up to source. Somebody's gotta go code
it.
Yeah. So
I don't really have a lot of other
questions on this unless you have another interesting
aspect mark to the
survey that you did. Do you have any
other Well, I
think, like, if if I could bring it
back to anything at all is that, like,
when you consider
what Tom just said is that maybe a
hybrid approach is the way to look at
this, that the CLI will always be there
and the APIs will continue to be developed
based on certain patterns. These are still developers
delivering to their customers at the end of
the day. And we need to consider the
fact that we might have to,
I guess, some people would say, abuse the
CLI for certain purposes if we're doing automation
and allow it to be a human interface,
you know, a user interface as Tom said
originally.
But going forward, we still have to remind
ourselves that
every time you look at systems,
I can't remember the first name, but a
man named Trist back in the nineteen fifties
was studying British coal mines. And he came
up with the concept of socio technical systems,
which has come forward and forward and forward
in many domains, DevOps, platform engineering, whatever. But
the the consensus was that no matter what
the system is, when you bring automation into
it, it's always about the interaction between humans
and the machines. Not just the machines,
not just the humans.
Right? So, there's this little comic once,
little comic that's really popular on the website
or, XKCD,
x k c d seven one seven eight
two. It's got entitled team chat and it
was talking about how back in the day,
everyone used to use IRC. But then slowly,
people started to move to Skype and that
most of the team was still using IRC.
Then almost everybody moved to Slack, but a
few people had the bridge via IRC to
get in. And it makes this joke that
far in the future,
most universe will reach
complete singularity, but there'll be that one person
who still has the IRC bridge to connect
in. He says, I have it just the
way I like. Right? Yeah. So it's the
same thing as, like, having, like, secure CRT
scripts
to really manipulate that iOSXR
system at 2AM and fix it faster than
anyone else could trying to reconcile it via,
you know, a source of truth, a modeling
tool or anything like that. Right? Trying to
say, like, infrastructure as code, that person will
triage circles around you because they understand the
patterns
of that system and it works best for
them.
So,
in this whole argument of pets versus cattle
that I've kind of brought up recently, I
think that the CLI
can be advanced to become more of a
cattle dog. Right? It's like kind of a
pet for us. You can pet it, but
it's still herding
the cattle that is in the system, which
are prefixes,
interfaces,
all that data richness, which you can still
feed it ice cream. You can pet it.
You can name it. It's familiar, and it's
reliable in that sense. You can bring it
at home at night.
So I think that's kind of the advancement
that I'm seeing in in the space. People
are starting to understand that you can't go
fully on the technical side.
Can't go fully on the socio side. Right?
And and hinder advancement, you're gonna have to
find that balance.
My question is, does the animal moo or
does it bark?
Maybe both.
Yeah. Maybe a little bit of both. Right?
You think about the cattle, it's like, should
we tend to each individual prefix as if
it's, like, the individual needs of the cattle
or should we have sensors
for problems around these things? Right? And look
at those systems.
But when you're moving these prefixes around, maybe
the best way to do that is with
the cattle dog. And that's the CLI, in
my opinion. Cool. Awesome. I think that's a
good a good analogy.
So, Tom, anything else?
Nope. Nope. Okay. Alright. Mark, where can people
find you? Reach you? Do you blog? Do
you un
unblog? Or I guess
I when Tom gave up his neglected blog,
I said, this won't do. I need to
have a neglected blog. So I made I
got one out there for the community. So
you can find me at zeal networks dot
c a. But if you actually wanna see
content, then you can reach me on LinkedIn
or in the Packet Pushers community.
And I'll also be at AutoCon three, here
in Prague in a couple weeks. Awesome.
Alright. Tom, where can people reach you?
I'll be on LinkedIn inspiring other people to
build new electric plugs. That's awesome.
Alright. And I'm a slight. You can always
find me here at the hedge of rule
eleven dot tech
on LinkedIn occasionally on x, Twitter, whatever.
I'm telling you, if you're trying to find
me, you'll find me. I'm really, really hard
to find.
We know that your attention is important. We
live in an attention driven economy.
By the way, Paul, thanks, Mark. What am
I talking about? Mark, thanks for coming on.
I'm like wrapped around the brain today. My
brain is like completely messed up. Anyway, Mark,
thanks for coming on and talking about this,
an interesting topic.
And for our listeners,
again, we know we live in an attention
driven economy,
and we know that your time and attention
are very important. So we thank you for
listening all the way to the bitter end
of this
episode of the hedge, and we will catch
you next time.