<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Nikos,<br>
</p>
<div class="moz-cite-prefix">On 11/12/2019 9:36 π.μ., Nikos
Leontsinis wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM5PR04MB1195DE8A260D1B95EE7DD06FB05A0@DM5PR04MB1195.namprd04.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<div>
<div>
<p class="MsoNormal"><span lang="EL">Ερωτηση προς τους
ομιλητες του </span><span lang="EN-US">network</span><span
lang="EN-US">
</span><span lang="EN-US">automation</span><span lang="EL">:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EL"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EL">Τι κανουμε με τα </span><span
lang="EN-US">corner</span><span lang="EN-US">
</span><span lang="EN-US">cases</span><span lang="EL">;<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EL"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">We didn’t discover
America in 2019. Python and most of the tools did exist
well before that even in 2000<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Why we were not
automating the network back then?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Could it be the
answer is that the network at the time was more of an
enabler and now became more of<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">a commodity?</span></p>
</div>
</div>
</div>
</blockquote>
<p>This is also true. I would mostly focus on the following:</p>
<p>- immaturity of tools. Today we have frameworks, libraries and
abstraction levels (eg ansible, napalm) that allow you deal with
the essence of network automation without programmatically
worrying about transport, errors etc. All these are handled in a
much more abstracted layer. We are also much more mature in XML,
and I don't think that yaml even existed back then. This also
allows you not to share experience and code and not rediscover the
wheel. Nosql, and JSON play a significant role too. Many tools (eg
NMS) now have a XML or JSON api, that allows integration. Last but
not least, network gear is much more mature for automation -- see
non monolithic OS, netconf, agents or python running within the
device, telemetry and countless more features. Back then we had
CLI and SNMP.</p>
<p>- Necessity: The number of devices has grown; the complexity of
services has grown. Configurations have grown 10x or more times
bigger. Modern services have so many parameters that it is almost
impossible to tweak by hand or memory. For instance, EVPN/VXLAN
and SDN are impossible to deploy in scale without automation. At
the same time, the need for a reliable network has exploded. Back
then a few hours of downtime might be ok, now even a few seconds
have a huge impact.<br>
</p>
<blockquote type="cite"
cite="mid:DM5PR04MB1195DE8A260D1B95EE7DD06FB05A0@DM5PR04MB1195.namprd04.prod.outlook.com">
<div class="WordSection1">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">How much flexibility
are we prepared to sacrifice with automation?</span></p>
</div>
</div>
</div>
</blockquote>
<p>Valid point. This is a balance that has to be found for each
network. Networks that successfully automate have found this
balance, otherwise automation would have ollapsed in practice.<br>
</p>
<p>The question however, is not that much related to automation, but
to service catalog: How willing are you to provide flavors or
variations of services not described in your service catalog?</p>
<blockquote type="cite"
cite="mid:DM5PR04MB1195DE8A260D1B95EE7DD06FB05A0@DM5PR04MB1195.namprd04.prod.outlook.com">
<div class="WordSection1">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span>How
can we reconcile business requirements that require
design deviations and still ensure consistency
<o:p></o:p></p>
<p class="MsoNormal">and data model driven adoption?</p>
</div>
</div>
</div>
</blockquote>
Again, this translates to service catalogue. There are companies
that do not wish to have a service catalogue because they want to be
flexible to provide any service that the customer might imagine. For
such cases, automation is much more difficult and with limited
scope.<br>
<blockquote type="cite"
cite="mid:DM5PR04MB1195DE8A260D1B95EE7DD06FB05A0@DM5PR04MB1195.namprd04.prod.outlook.com">
<div class="WordSection1">
<div>
<div>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If we cannot how much design/model
deviation can we tolerate?</p>
</div>
</div>
</div>
</blockquote>
<p>It is hard to answer in a few sentences, but it is doable. You
need to have a relatively stable service catalogue, but small or
transient deviations can be handled in various ways.</p>
<p>At GRNET, for instance, we had the option for something like an
"override" file per device, which we would use as a last resort
for commands that could not be generated by our automation, just
to handle such kind of exceptions. Still, exceptions on such a
file where much better than exceptions arbitrarily "lost" within
the configuration of the router: They were gathered together so
that you could not miss them; they were commended so that we knew
why they were there; and git could track when and who inserted
them into our network.<br>
</p>
<blockquote type="cite"
cite="mid:DM5PR04MB1195DE8A260D1B95EE7DD06FB05A0@DM5PR04MB1195.namprd04.prod.outlook.com">
<div class="WordSection1">
<div>
<div>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There is a dark side of automation that
none wants to talk about…</p>
</div>
</div>
</div>
</blockquote>
<p>Actually we do :-) Most automation presentations talk about such
things, although they do not name it "dark side" but "challenges",
"todo", "caveats"...<br>
</p>
<p>But I get your point. Maybe we can have a panel at next GRNOG
about that.</p>
<p>BR,<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:DM5PR04MB1195DE8A260D1B95EE7DD06FB05A0@DM5PR04MB1195.namprd04.prod.outlook.com">
<div class="WordSection1">
<div>
<div>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">nikos<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
</div>
This email is from Equinix (EMEA) B.V. or one of its associated
companies in the territory from where this email has been sent.
This email, and any files transmitted with it, contains
information which is confidential, is solely for the use of the
intended recipient and may be legally privileged. If you have
received this email in error, please notify the sender and delete
this email immediately. Equinix (EMEA) B.V.. Registered Office:
Amstelplein 1, 1096 HA Amsterdam, The Netherlands. Registered in
The Netherlands No. 57577889.
</blockquote>
</body>
</html>