[Nemops-interest] Re: NEMOPS Workshop Report

[Michael Richardson <[e-mail]>]

Thank you for the write up.

Dhruv Dhody <[e-mail]> wrote:
    > Wes and I have posted the initial version of the NEMOPS Workshop Report -

    > https://datatracker.ietf.org/doc/draft-iab-nemops-workshop-report/
    > https://www.ietf.org/archive/id/draft-iab-nemops-workshop-report-01.html

    > We’d appreciate your feedback, ideally on the [e-mail] list
    > or directly to the authors. You can also submit a PR on GitHub:

}   Many operators
}   prioritize operational conferences over standards development
}   organizations (SDOs), such as RIPE, NANOG, APRICOT, LACNIC, AutoConn,
}   etc.
}
}   To address this, the IAB workshop's Program Committee (PC) planned
}   outreach initiatives to foster discussions and gather interest by
}   engaging with operators at these venues and conducting information/
}   requirement-gathering sessions.  Participants were encouraged to

Did we succeed in getting more operators to the workshop?
I observed the PC outreach at RIPE89, but I'm not sure it resulted in the
groundswell that was desired.

Yesterday, I walked a new (very young) network admin through adding a new
[not new to us, just been sitting in a box since 2019] switch CREDIL.org's
network monitoring tool... That is, we connected it to SNMP...
The level of idiosyncracy is great, caused in large part by
heterogeneous equipment which is definitely not new.
We (had to) fixed quite a number of things along the way, so it took about 5 hours.
This was the new person's first experience with Cisco-style router CLIs, and
she was really impressed with how useful completion was.  We used a Web
interface for a bit to add a static IPv6 for the control access, but the Web
interface *did the wrong thing*.  We never spoke of YANG.
We use tftp to backup configurations, which we then manually check into git.
("git app -p" is very good way to review what you actually did, and also to
learn what went wrong with the web interface attempt)

We'd love to use scp, but the security posture of it is almost worse.
We also never get ssh access to our switches to work consistently, so serial
consoles are mandatory as backup, and guess what: RESTCONF does not work
across that link.   RFC8994 would be nice.
(Yes, I have running code)

I don't think section 3.1.3 really articulates this well enough:
"Additionally, the lack of
 simple tools for smaller networks operating under tight timelines and
 budgets was emphasized."

this is just insufficient emphasis here.
I could think to replace all of section 3.1.x with:
  "Additionally, the lack of
   simple tools other than Net-SNMP for smaller networks operating under
   tight timelines, a mix of older and newer systems and very small budgets
   was emphasized."

Organizations slightly larger than CREDIL typically "solve" these problems
by buying all same-vendor equipment every ~10 years or so.  It comes with a
thick manual which one person reads, just before being lured away by higher
salary to be an Application Engineer for said vendor.  If they were rich at
the time, or the discount was large, they bought the management platform with
a pretty interface, but in practice no ability to do anything really useful.

section 3.2 seems to all be about problems with managing systems at larger
scale.  My complaint all along is that RESTCONF(YANG) does not scale.  Scale doesn't
mean "big", it means, something can work from smallest to largest scale. RESTCONF
doesn't work in the small.  One never starts a three switch network with
RESTCONF, and then use it as you grow.  One starts with a three hundred
switch network.

Lots of talk about open source, but not really any mention of how such a
thing could be funded.  That's really the problem.


}   1.  In network deployments, operations are typically at the bottom of
}       the ladder.  It's the most squeezed for time and resources.
}       Network engineers are not typically seasoned developers.

It's way way worse than that.  Most government and NGO network engineers are
prevented by policy (from their own organization!) from even having developer
tools on their desktop.  Getting access to equipment to do testing on (like
developing new tools) is essentially impossible in many places.

}   4.  It was suggested that other domains (e.g., K8N/automation) are
}       years ahead of the current network engineering stack.

k8n has useless networking.  It's "years ahead", in that it does a few things
autonomically, but does them wrong.  Managers are told the wrong way is "better"

}   5.  There was a point about navigating non-device-specific models
}       being difficult.  If understood correctly, the Network Engineer
}       knows the CLI command but has trouble grepping for it in YANG
}       modules defined by SDOs.

I can discover most anything in the CLI by hitting TAB/? enough.
One switches and routers which I've never touched or read the manual for.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [





--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide