Subject: [netmod] Clarifications re RFC 8342 NMDA

From: Jonathan <[email-masked]>
Date: Thu, 02 Jan 2020 17:12:30 +0000

Hi,

I have been reading through RFC 8342 and have a number of questions I 
couldn't resolve after a couple of passes through. Can anyone advise?
The RFC states "The startup configuration datastore may not be supported 
by all protocols or implementations", "the candidate configuration 
datastore may not be supported by all protocols or implementations" and 
"<running> MUST be supported if the device can be configured via 
conventional configuration datastores". I can find no explicit guidance 
on:The intended configuration datastore: The RFC does state, "Whenever 
data is written to <running>, the server MUST also immediately update 
and validate <intended>." Is <intended> mandatory for NMDA-supporting 
servers that support <running>?The operational state datastore: The RFC 
does state it is "a read-only datastore that consists of all "config 
true" and "config false" nodes defined in the datastore's schema" and 
that "the datastore schema for <operational> MUST be a superset of the 
combined datastore schema used in all configuration datastores ...". Is 
<operational> mandatory for NMDA-supporting servers?RFC 8525, section 1 
states, "For backwards compatibility, an NMDA-supporting server SHOULD 
populate the deprecated "/modules-state" tree in a backwards-compatible 
manner."That suggests an NMDA-supporting server SHOULD be 
backwards-compatible with a non-NMDA-supporting client. Is that 
correct?Can an MMDA-supporting client be backwards-compatible with a 
non-NMDA-supporting server?I can't find any mention of YANG version 1 in 
RFC 8342. Is it safe to assume NMDA is compatible with YANG version 1 
modules?
Thanks,

Jonathan

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 2 Jan 2020 18:37:06 +0000

On Thu, Jan 02, 2020 at 05:12:30PM +0000, Jonathan wrote:
> The RFC states "The startup configuration datastore may not be supported by
> all protocols or implementations", "the candidate configuration datastore
> may not be supported by all protocols or implementations" and "<running>
> MUST be supported if the device can be configured via conventional
> configuration datastores". I can find no explicit guidance on:The intended
> configuration datastore: The RFC does state, "Whenever data is written to
> <running>, the server MUST also immediately update and validate <intended>."
> Is <intended> mandatory for NMDA-supporting servers that support
> <running>?

It is not mandatory to expose <intended>. On simple implementations,
<intended> may be identical with <running>.

> The operational state datastore: The RFC does state it is "a
> read-only datastore that consists of all "config true" and "config false"
> nodes defined in the datastore's schema" and that "the datastore schema for
> <operational> MUST be a superset of the combined datastore schema used in
> all configuration datastores ...". Is <operational> mandatory for
> NMDA-supporting servers?

Since <operational> is the only way to expose config false nodes for
an NMDA server, it is kind of mandatory as soon as you have config
false nodes to expose.

> RFC 8525, section 1 states, "For backwards
> compatibility, an NMDA-supporting server SHOULD populate the deprecated
> "/modules-state" tree in a backwards-compatible manner."That suggests an
> NMDA-supporting server SHOULD be backwards-compatible with a
> non-NMDA-supporting client. Is that correct?

This might be a misuse of 'SHOULD' since backwards-compatibility is
important for a transition phase but not in pure NMDA environments.
The idea here was to encourage support for a transition phase where
NMDA and non-NMDA implementations may need to co-exist.

> Can an MMDA-supporting client be
> backwards-compatible with a non-NMDA-supporting server?

An NMDA client should talk NMDA with an NMDA server. Whether an NMDA
client also talks to non-NMDA servers is up to the implementor. I
personally would distinguish between the protocol interaction and the
data model of the management application. To me, it makes a lot of
sense to make the data model of the management application NMDA aware
even if the application is used with non-NMDA servers.

> I can't find any
> mention of YANG version 1 in RFC 8342. Is it safe to assume NMDA is
> compatible with YANG version 1 modules?

It should not matter whether the model is written in YANG 1 or 1.1.
However, core data models are moving towards YANG 1.1.

/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/>

---

From: Jonathan <[email-masked]>
Date: Fri, 03 Jan 2020 11:39:31 +0000

------ Original Message ------
From: "Schönwälder, Jürgen" <[email-masked]>
To: "Jonathan" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 02/01/2020 18:37:06
Subject: Re: [netmod] Clarifications re RFC 8342 NMDA

>an NMDA server, it is kind of mandatory as soon as you have config
RFC 6241 describes <get> as retrieving "running configuration and device 
state information" and <get-config> as retrieving "all or part of a 
specified configuration datastore". RFC 8526 introduces <get-data> which 
it describes as "similar to NETCONF's <get-config> operation". As far as 
I can tell, neither RFC 8342 not RFC 8526 actually identify which 
operation to use to retrieve operational state data. Am I right in 
assuming it would be <get-config>? In that case, it is similar to <get> 
when performed on <operational> as it will also return state data.

And what should be the result of performing <get> on an NMDA-supporting 
server? Should it still return config true nodes from <running> plus 
config false nodes from <operational>? Or should the operation be 
rejected?

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Fri, 3 Jan 2020 15:43:31 +0000

> specified configuration datastore". RFC 8526 introduces <get-data> which it
> describes as "similar to NETCONF's <get-config> operation". As far as I can
> tell, neither RFC 8342 not RFC 8526 actually identify which operation to use
> to retrieve operational state data. Am I right in assuming it would be
> <get-config>? In that case, it is similar to <get> when performed on
> <operational> as it will also return state data.

There is quite some discussion of 'operational state datastore' in
subsections of section 3.1.1 'The <get-data> Operation' in RFC 8526.
There is also an example in section 3.1.1.4.

The <get-config> operation returns config data, hence it won't return
config false data, i.e., its not a good choice for <operational>. The
reason why we have NMDA is that <get> semantics have been found to be
problematic. Hence, NMDA systems should use RFC 8526 operations
(<get-data> and <edit-data>) when talking to each other.

> server? Should it still return config true nodes from <running> plus config
> false nodes from <operational>? Or should the operation be rejected?

A proper NMDA client should never send a <get>. Supporting <get> only
makes sense for legacy clients and they might expect RFC 6241
behaviour as far as that is implementable (the reason we have NMDA is
that <get> semantics assume that <running> is identical to <applied>
config, which is just not always true).

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Jan 2020 08:05:55 -0800

On Fri, Jan 3, 2020 at 7:43 AM Schönwälder, Jürgen <
[email-masked]> wrote:

> it
> config

This issue has been discussed quite a bit.
RFC 8526 does not change RFC 6241 in any way. Period.
The implementation of <get>, <get-config>, and <edit-config> are
not changed at all if NMDA is also supported by the server.

/js
Andy

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