Re: [netconf] A case for vendors to move to RESTCONF?

[Qin Wu <[e-mail]>]

Hi, Med, Kent:
I need to better keep track of RESTCONF, NETCONF, YANG related issues
https://github.com/netmod-wg/yang-next
https://github.com/netconf-wg/restconf-next/issues
https://github.com/netconf-wg/netconf-next/issues
I can feel these issues can be good input to  https://github.com/boucadair/rfc3535-20years-later
We also can see in the other way around, i.e.,issues collect from github on rfc3535-20years-later can also be input to
https://github.com/netmod-wg/yang-next
https://github.com/netconf-wg/restconf-next/issues
https://github.com/netconf-wg/netconf-next/issues
I can see all these initiatives are complementary, one focuses on requirements, the other focuses on potential solution to address  these requirements.
One is operator driven (yes, vendor can also contribute), the other is community member driven including both vendors and operators.
But we need to see them better coordinate in a systematic way.

-Qin
发件人: netconf [mailto:[e-mail]] 代表 [e-mail]
发送时间: 2024年4月23日 15:40
收件人: [e-mail]
抄送: [e-mail]; [e-mail]
主题: Re: [netconf] A case for vendors to move to RESTCONF?

Hi Albrecht, all,

Thank you for sharing your thoughts.

FWIW, NMOP WG has a chartered item to discuss  issues faced by the deployment of existing network management technologies, including challenge some of the IETF solutions [2]. The tooling and abstraction issues are part them. The document which we use to collect these is [2]. We accept PRs at [3] ;-)

Cheers,
Med

[1] https://datatracker.ietf.org/meeting/119/materials/slides-119-nmop-an-update-of-operators-requirements-on-network-management-protocols-and-modelling-02
[2] https://datatracker.ietf.org/doc/draft-boucadair-nmop-rfc3535-20years-later/
[3] https://github.com/boucadair/rfc3535-20years-later

De : netconf <[e-mail]<mailto:[e-mail]>> De la part de Schwarz Albrecht (ETAS-DAP/XPC-Fe6)
Envoyé : mardi 23 avril 2024 08:18
À : Andy Bierman <[e-mail]<mailto:[e-mail]>>; Kent Watsen <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>
Objet : Re: [netconf] A case for vendors to move to RESTCONF?

That consideration and discussion is incomplete in my understanding (because limited on the protocol endpoint functions only).

Let’s name it the YCONF family of management protocols (NETCONF, RESTCONF, CORECONF, gNMI).
These are all application layer protocols.
A complete evaluation got to consider the served user instances too, i.e. the applications on top.
That’s the management architecture (of distributed systems) with management manager function and management agent functiosn associated to YCONF client and server endpoints respectively.

The real issue are not the YCONF clients, rather the application function “management manager” (whether as element manager, network manager, business manager, policy manager, security manager, telemetry manager …).

What might be beneficial would be e.g., an open source applications suite for management managers something like
·         a basic App as core manager application function
·         a HMI App for a basic (graphical) user interface
and an App store of dedicated management manager application functions such as
·         App “discovery of topological models at system abstraction level …”
·         App “inventory of x with scope on y”
·         App “configuration management for …”
·         App “fault management for self-healing at agent level”
·         App “alarm management for …”
·         App “operational state supervision of …”
·         App “performance monitoring of “
·         App “security management for … e.g., TLS”
·         App “SW/FW image update”
·         etc etc

Think you got the point. Apps might be divided in basic functionality plus complementary Apps for added-value services.
There might be hundreds of such Apps.
An App store.as open source approach.

That would be the real accelerator and push for YCONF clients.
And No, neither YANG nor YCONF was a mistake!

The management manager application function business was in the past a more or less closed ecosystem of ICT and IT vendors of network infrastructure and network service manufactures.
No surprise that there isn’t yet such an open source App store approach in that business domain.

Some thoughts,
Albrecht



Dr. Albrecht Schwarz
Systems Engineer

T [phone]
M [phone]
[e-mail]<mailto:[e-mail]>

ETAS GmbH, ETAS-DAP/XPC-Fe6
Borsigstraße 24, 70469 Stuttgart, Germany
www.etas.com<http://www.etas.com/>

ETAS – Empowering Tomorrow’s Automotive Software

Managing Directors: Dr. Thomas Irawan, Nicolet Eglseder, Mariella Minutolo
Chairman of the Supervisory Board: Dr. Walter Schirm
Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB: 19033
​
From: netconf <[e-mail]<mailto:[e-mail]>> On Behalf Of Andy Bierman
Sent: Montag, 22. April 2024 23:32
To: Kent Watsen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [netconf] A case for vendors to move to RESTCONF?



On Mon, Apr 22, 2024 at 9:57 AM Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:
At NANOG 90, Rob Shakir used his Keynote in part to make a point that there are not that many NETCONF clients:  https://youtu.be/uOWxogW5Ubg?t=1721



Very interesting talk.
I do not agree that YANG was a mistake, but no argument about the scarcity of tools.
Network Tool Automation is complicated and high-level operations are complicated.
It will probably never be as general-purpose as gRPC.


This a true, as NETCONF is purpose specific.   On the other hand, RESTCONF is just HTTP, and one can easily argue that there are many more HTTP clients than gRPC clients.

If NETCONF client proliferation is being held up as the poster-child for the impediment of deployment velocity, it seems obvious that RESTCONF (for NEs) would more than level that position.

NE vendors should support RESTCONF (with JSON encoding) on their devices, so that their devices are easier integration targets, for both application and script developers.


YANG allows the server developer to implement to the YANG model and not the protocol.
The clients can pick and choose between several northbound protocols.
Each protocol defines how to map YANG statements to protocol messages.
It will never be one-size-fits-all.


Kent  // an individual contributor

Andy


_______________________________________________
netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.