Subject: [netmod] Management Protocol Roles: Client/Server vs Manager/Agent

From: "Schwarz Albrecht (ETAS/ESY1)" <[email-masked]>
Date: Fri, 3 May 2019 10:43:50 +0000

Hello Andy, Juergen,

I got a side question for clarification (which was perhaps already discussed years ago on the list, but I'm just starting to follow NETCONF & NETMOD activities):

The management paradigm and management association is related to roles (Management) Manager (or Master) and (Management) Agents, in an hierarchical relationship of 1:N concerning the ratio of Manager to Agents.
That's the usual case, being aware of the exceptional cases with e.g. M:N (or additional, interim Management Broker, Gateway, etc entities).

I would have expected that 
- the Management Data Modeling language (YANG),
- the Management Datastore Architecture (RFC 8342),
- a Network Configuration Access Control Model (RFC 8341) and even
- Network Management Protocols for YANG data (such as NETCONF, RESTCONF)
use the role model of Manager and Agent.
However, I do see only the role relationship Client/Server (in that RFCs), hm?

Leading (for me) to a principle dilemma from (management) protocol engineering perspective due to
a) Manager-to-Agent = 1:N
b) Client-to-Server = N:1
c) and the mapping approach in NETCONF/NETMOD of Manager-to-Client and Agent-to-Server in my understanding.

I'm being aware that a distributed management solution needs to resolve the various role assignments in a layered management communication architecture at the various levels, e.g.,
for Management Application MA-over-RESTCONF-over-HTTP-over-TCP-over- ... as
1) Application level (MA): Manager to Agent(s)
2) Application layer management protocol = RESTCONF: Manager to Agent(s)
3) Session layer = HTTP: Client(s) to Server
4) Transport layer = TCP: Client(s) to Server

I fail to see, or do miss the background/justification why the notion of client/server is used in RFCs about YANG, NMDA, NETCONF? Instead of manager/agent.

Does anyone know the motivation, background?

Thanks,
Albrecht

Mit freundlichen Grüßen / Best regards

Dr. Albrecht Schwarz

Systems Engineering (ETAS/ESY1) 
Tel. +49 711 3423-2380 | Mobil +49 173 9792 632 | [email-masked]

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Juergen Schoenwaelder
Sent: 03 May 2019 11:20
To: Andy Bierman <[email-masked]>
Cc: NetMod WG <[email-masked]>
Subject: Re: [netmod] validating a YANG action

On Fri, May 03, 2019 at 01:10:58AM -0700, Andy Bierman wrote:
> On Thu, May 2, 2019 at 10:57 PM Juergen Schoenwaelder < 
> [email-masked]> wrote:
> 
> > On Thu, May 02, 2019 at 04:15:28PM -0700, Andy Bierman wrote:
> > > Hi,
> > >
> > > The text about invoking actions in RFC 7950, sec. 7.15 is not 
> > > clear about whether the ancestor data nodes have to exist.
> > >
> > > sec 7.15.2, para 2:
> > >
> > >    The <action> element contains a hierarchy of nodes that 
> > > identifies the node in the datastore.
> > >
> > >
> > > The RFC does not say anything about if the data node is required 
> > > to exist or not.  There is no distinction between NP-container, 
> > > P-container, or list which are ancestors of the action node. It 
> > > does not specify which datastore, and that is not supplied in the <action> RPC.
> > > The text specifies what must be in the <rpc> request, not in any
> > datastore
> > > or state data.
> > >
> > > It seems like the intent is that no instance test is specified at 
> > > all and the corresponding ancestor nodes to the action node do not 
> > > have to exist for the action to be invoked. (The action may succeed or fail).
> > > The issue is whether there is an existence-test before invoking 
> > > the
> > action.
> >
> > We discussed actions during the work on NMDA. RFC 8342 has this text 
> > in section 6, in particular 6.1 says:
> >
> >    Actions are always invoked in the context of the operational state
> >    datastore.  The node for which the action is invoked MUST exist in
> >    the operational state datastore.
> >
> >
> This only applies to a server implementing NMDA.
> There is no requirement for a server implementing RFC 7950 to make 
> this test.
>

Yes, the behavior is unspecified in RFC 7950. However, note that RFC
8342 formally updates RFC 7950 and the Introduction section says:

   This document updates RFC 7950 by refining the definition of the
   accessible tree for some XML Path Language (XPath) context (see
   Section 6.1) and the invocation context of operations (see
   Section 6.2).

This update may not affect your implementation but since you asked whether there is an existence-test before invoking the action, I thought a pointer to RFC 8342 is perhaps relevant.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 May 2019 18:14:50 +0200

> c) and the mapping approach in NETCONF/NETMOD of Manager-to-Client and Agent-to-Server in my understanding.

The problem is that you leave the plural 's' out. ;-)

Client-to-Server  is 1:1 (= Manager-to-Agent)
Client-to-Servers is 1:N (= Manager-to-Agents)
Clients-to-Server is N:1 (= Managers-to-Agent)

> I fail to see, or do miss the background/justification why the notion of client/server is used in RFCs about YANG, NMDA, NETCONF? Instead of manager/agent.

It all boils down how you define the terms Manager and Agent. With
NETCONF/RESTCONF and YANG, the initial focus was on the interaction
between the server maintaining configuration datastores and the client
manipulating configuration datastores (leaving out notifications for
now, they actually came later).

/js

---

From: "Schwarz Albrecht (ETAS/ESY1)" <[email-masked]>
Date: Mon, 6 May 2019 15:24:28 +0000

Hello Juergen,

thanks for feedback!

> It all boils down how you define the terms Manager and Agent. With NETCONF/RESTCONF and YANG, the initial focus was on the interaction between the server maintaining configuration datastores and the client manipulating configuration datastores (leaving out notifications for now, they actually came later).

The relevant role semantics originate at application level (and not at lower levels such as specific protocol layers), i.e., management applications (= the primary scope of NETCONF/RESTCONF).
That (native) roles are defined in ITU-T Recommendations X.701, M.3010, M.3700, and others, and in RFCs 3411, 3413, 3512, and others (in case of SNMP).
Crucial, underlying concept is the Management Application Context (often simply "context" in SNMP RFCs).
A manager gots normally exclusive access to a specific management application context. Multiple manager usually don't share the same application context (due to access conflicts, synchronization issues, etc).
That's why the 1:N ratio of management manager to management agent(s).

(I'm aware that these high-level management roles are further refined by e.g. considering the sub-roles of command generator, command responder, notification originator, notification receiver), see RFC 3413 or ITU-T X.703.)

Now, I had in mind that in client/server applications an application context is normally not distributed over multiple servers (but I might be wrong).

Anyway, looks like that I found in the meanwhile a hint to my question in RFC 6632, clause 1.3, stating the equation of:
(Management) Agent = NETCONF Management Server
(Management) Manager = NETCONF Management Client

Thanks again!
Albrecht

PS
An interesting exercise (for students?:-) might be the attempt to map NETCONF management roles on the distributed management architecture of ITU-T X.703, which differentiates the four roles of
- Managing client
- Managing server
- Managed client
- Managed server
with "Managing" = "Manager" and "Managed" = "Agent". :-)

Dr. Albrecht Schwarz

-----Original Message-----
From: Juergen Schoenwaelder <[email-masked]> 
Sent: 03 May 2019 18:15
To: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>
Cc: Andy Bierman <[email-masked]>; NetMod WG <[email-masked]>
Subject: Re: Management Protocol Roles: Client/Server vs Manager/Agent

Client-to-Server  is 1:1 (= Manager-to-Agent) Client-to-Servers is 1:N (= Manager-to-Agents) Clients-to-Server is N:1 (= Managers-to-Agent)

> I'm being aware that a distributed management solution needs to 
> resolve the various role assignments in a layered management 
> communication architecture at the various levels, e.g., for Management 
> Application MA-over-RESTCONF-over-HTTP-over-TCP-over- ... as

It all boils down how you define the terms Manager and Agent. With NETCONF/RESTCONF and YANG, the initial focus was on the interaction between the server maintaining configuration datastores and the client manipulating configuration datastores (leaving out notifications for now, they actually came later).

/js

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 6 May 2019 20:36:33 -0700

Hi -

On 5/6/2019 8:24 AM, Schwarz Albrecht (ETAS/ESY1) wrote:
...
> The relevant role semantics originate at application level (and not
> at lower levels such as specific protocol layers), i.e., management
> applications (= the primary scope of NETCONF/RESTCONF).
> That (native) roles are defined in ITU-T Recommendations X.701, M.3010, M.3700,
> and others, and in RFCs 3411, 3413, 3512, and others (in case of SNMP).

No.  The concept of "application context" as used in X.701 has no
equivalent in the SNMP universe.  It's needed in X.701 because of
the decision to permit the negotiation of roles upon establishment
of an association.  In fundamentally connectionless SNMP, such
negotiation would make no sense.

When the word  "context" is used in the SNMP universe, it refers
to a completely different concept, one introduced primarily in
order to work around deficiencies in the naming architecture resulting
from MIB modules using the SMI.  See, for example, RFC 3415.

> A manager gots normally exclusive access to a specific management
> application context.

Not true in either the CMIP nor in the SNMP universes.

> Multiple manager usually don't share the same application context

Not true in either the CMIP nor in the SNMP universes, and not
true for either meaning of the word "context".

> (due to access conflicts, synchronization issues, etc).

No, that's why, for example, things like VACM and the
the TestAndIncr textual convention are used in the SNMP
world, and why a rudimentary locking facility has been
present in Netconf since the early days.

> That's why the 1:N ratio of management manager to management agent(s).

That's not a realistic assumption for any kind of
"industrial-strength" management architecture.

> (I'm aware that these high-level management roles are further refined
> by e.g. considering the sub-roles of command generator, command responder,
> notification originator, notification receiver), see RFC 3413 or ITU-T X.703.)

I would not rely on X.703 as a source of terminological clarity in
this forum.  As an attempt to re-frame CMIP in terms of CORBA-speak,
it long post-dates the split between the IETF and ISO/ITU communities.
As for RFC 3413, I think we were abundantly clear that the use of the
"sub-roles" was fore purely expository purposes, and that whether
there might be any corresponding division within an implementation
would be, well, an implementation matter.

> Now, I had in mind that in client/server applications an application
> context is normally not distributed over multiple servers (but I might
> be wrong).
...

Consider, for example, aggregating management proxies.
The "disman" MIBS should provide ample examples.

Randy

---

From: "Schwarz Albrecht (ETAS/ESY1)" <[email-masked]>
Date: Wed, 8 May 2019 09:34:24 +0000

Thanks Randy for your comments and insights in the history of that management technologies!
Helpful, appreciated!
Albrecht

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Randy Presuhn
Sent: 07 May 2019 05:37
To: [email-masked]
Subject: Re: [netmod] Management Protocol Roles: Client/Server vs Manager/Agent

Hi -

....
> The relevant role semantics originate at application level (and not at 
> lower levels such as specific protocol layers), i.e., management 
> That (native) roles are defined in ITU-T Recommendations X.701, 
> M.3010, M.3700, and others, and in RFCs 3411, 3413, 3512, and others (in case of SNMP).

No.  The concept of "application context" as used in X.701 has no equivalent in the SNMP universe.  It's needed in X.701 because of the decision to permit the negotiation of roles upon establishment of an association.  In fundamentally connectionless SNMP, such negotiation would make no sense.

When the word  "context" is used in the SNMP universe, it refers to a completely different concept, one introduced primarily in order to work around deficiencies in the naming architecture resulting from MIB modules using the SMI.  See, for example, RFC 3415.

> Multiple manager usually don't share the same application context

Not true in either the CMIP nor in the SNMP universes, and not true for either meaning of the word "context".

> (due to access conflicts, synchronization issues, etc).

No, that's why, for example, things like VACM and the the TestAndIncr textual convention are used in the SNMP world, and why a rudimentary locking facility has been present in Netconf since the early days.

> That's why the 1:N ratio of management manager to management agent(s).

That's not a realistic assumption for any kind of "industrial-strength" management architecture.

> by e.g. considering the sub-roles of command generator, command 
> responder, notification originator, notification receiver), see RFC 
> 3413 or ITU-T X.703.)

I would not rely on X.703 as a source of terminological clarity in this forum.  As an attempt to re-frame CMIP in terms of CORBA-speak, it long post-dates the split between the IETF and ISO/ITU communities.
As for RFC 3413, I think we were abundantly clear that the use of the "sub-roles" was fore purely expository purposes, and that whether there might be any corresponding division within an implementation would be, well, an implementation matter.

> context is normally not distributed over multiple servers (but I might 
....

Randy