[Nemops-interest] Re: [Nemops-workshop-attendees] NEMOPS Workshop Report

Michael Richardson <mcr@sandelman.ca> Fri, 28 February 2025 17:28 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: nemops-interest@mail2.ietf.org
Delivered-To: nemops-interest@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 2E4583E458E; Fri, 28 Feb 2025 09:28:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level:
X-Spam-Status: No, score=-4.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1WcgYSp5UUh; Fri, 28 Feb 2025 09:28:14 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id C62AF3E4570; Fri, 28 Feb 2025 09:28:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3B0991800E; Fri, 28 Feb 2025 12:28:13 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavis, port 10024) with LMTP id Mp8fSAyt_hqD; Fri, 28 Feb 2025 12:28:11 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1740763691; bh=ErzBtYvjnYjFKhetfb7NpXZyyEB1exv6yn/qJgBiiGE=; h=From:To:Subject:In-Reply-To:References:Date:From; b=s2TNaEWbfGcAato9EMVapBtPZxw8yYOA7opFozG2tRUkpwcKD+fG4gm8GJZuWvof5 bHCEGQowNvei86kfJTe8I2EqC9BKLcJmTm6oNLZu4phqk3RG4H4qIySQIHXElAYlHN HTZHn8delGKGEQI+tG/rqj1aepr8oNL1p3/gr6OgeHOeyT9i0lKu/SZuuBummOCvJU nItq06SFRgKDtZ2304l9slxAZWrq0+rRU7ffK5UjzuxHGcaoSSQBTW/Y4rRb1eu6zq ASBgmKTqLag7OzC6pTDGJCmz8Sc+h0OF9kPPuBxNICSGJHXJ7eLo6MF4QNFdMppwMm bQxI2t/Rsqibw==
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AA0C01800C; Fri, 28 Feb 2025 12:28:11 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9B03A31F; Fri, 28 Feb 2025 12:28:11 -0500 (EST)
From: Michael Richardson <mcr@sandelman.ca>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, nemops-interest@iab.org, architecture-discuss@iab.org, nemops-workshop-attendees@iab.org
In-Reply-To: <049038BD-C9DC-4BAA-AF66-DACF3530504F@gmail.com>
References: <CAP7zK5YV5s2-0jutfN0mg3CBUNbZgA4KJbkFdqFXvbEqphsj-Q@mail.gmail.com> <30029.1740080212@obiwan.sandelman.ca> <87frk8i9og.fsf@centor.se> <17614.1740090407@obiwan.sandelman.ca> <049038BD-C9DC-4BAA-AF66-DACF3530504F@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 28 Feb 2025 12:28:11 -0500
Message-ID: <8627.1740763691@obiwan.sandelman.ca>
Message-ID-Hash: SVV7FHAJXR4ZZTSTCHKFAFYLVKFYWD2O
X-Message-ID-Hash: SVV7FHAJXR4ZZTSTCHKFAFYLVKFYWD2O
X-MailFrom: mcr@sandelman.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Nemops-interest] Re: [Nemops-workshop-attendees] NEMOPS Workshop Report
List-Id: Next Era of Network Management Operations <nemops-interest.iab.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nemops-interest/mixbq_UJAV3Pyebz_Knf7NhFdNM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nemops-interest>
List-Help: <mailto:nemops-interest-request@iab.org?subject=help>
List-Owner: <mailto:nemops-interest-owner@iab.org>
List-Post: <mailto:nemops-interest@iab.org>
List-Subscribe: <mailto:nemops-interest-join@iab.org>
List-Unsubscribe: <mailto:nemops-interest-leave@iab.org>

Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
    >> 2. Ergo, no new people will ever learn it until RESTCONF is sufficiently
    >> ubiquitous that it would be the best and easiest way to get something done.

    > I know that Arrcus, Cisco, Nokia, and Juniper support
    > NETCONF/RESTCONF. I am happy to point you to a VM/Docker instance of
    > ArcOS that will allow you to play with its RESTCONF or NETCONF
    > interface with an OpenAPI documentation set. I am not trying to sell my
    > product, just demonstrating that there are plenty of platforms/NOS that
    > support this interface.

Is Arccus a switch operating system, or an Orchestrator?
https://arrcus.com/connected-edge/arcos says it's a switch operating system
I guess it competes with, for instance, VyOS?

I'm not sure people understood just how important NetSNMP was.
It wasn't just a client, but also a server.

    >>> it. I can’t relate at all with your claim that RESTCONF does not scale
    >>> down. What do you mean? What prevents you from using it? Be specific
    >>> please.
    >>
    >> I'm sure an Orchestrator could tell my two switches (from different vendors,
    >> say) provide a trunk VLAN on some set of ports, but setting that up takes
    >> more resources than just learning how to program two CLIs.

    > Like most programming projects, the initial learning curve is always
    > high. I would suggest that you spend some time going through this

So I'm trying to advocate for others with less experience.
If the learning curve is too high, then it won't happen.
It's not what *I* can learn, but what I can motivate others to learn.

Today, RESTCONF does not seem to be a superset of what SNMP MIBs can do today.
I'm not saying that it true, but it doesn't seem that way.

As a *really minor*, but super useful thing, the number 1 and 2 things that
we use Observium is to note which switch port is attached to which other system.
That uses the fact that the switches collect LLDP information into their MIB.
I'm unaware of any plugin for Observium (or other equivalent systems) that
would do all the SNMP read-only stuff I'm used to, but via RESTCONF.

    > presentation by Roman Dodin on how he went about trying to automate his
    > network, in addition to what Kristian mentions below.

    > https://www.youtube.com/watch?v=oClamTj4LiY <https://www.youtube.com/watch?v=oClamTj4LiY>

Thank you.