Subject: [netmod] Must offline-validation of <running> alone be valid?

From: "maqiufang (A)" <[email-masked]>
Date: Mon, 22 Nov 2021 12:07:54 +0000

Hi, all
Regarding the presentation of "system-defined configuration(draft-ma-netmod-with-system)" in IETF 112, I would like to initiate a separate thread to discuss "MUST offline-validation of <running> alone be valid".
This is unknown if any RFC requires offline validation of <running>. Then the choices become:

     *   Offline validation of <running> alone is NOT required
        *   Servers internally validate <running> via validating <intended>
     *   Offline validation of <running> alone IS required
        *   Options:
           *   Clients MUST copy/paste any referenced system configuration into <running>, even though it goes against our objective of avoiding-copy when possible.
           *   Defer work to be a YANG-next effort.
Any thoughts on this?

Best Regards,
Qiufang Ma

---

From: Jan Lindblad <[email-masked]>
Date: Tue, 23 Nov 2021 10:59:18 +0100

Qiufang,

> Regarding the presentation of “system-defined configuration(draft-ma-netmod-with-system)” in IETF 112, I would like to initiate a separate thread to discuss “MUST offline-validation of <running> alone be valid”.

Thank you for bringing this up again.

> This is unknown if any RFC requires offline validation of <running>.

I do not consider this unknown. RFC 7950 is quite clear on the subject, with numerous statements about configuration validity that are incompatible with the current draft text. The most obvious contradiction is the last paragraph of section 8.1, which consists of a single sentence:

   The running configuration datastore MUST always be valid.

If you read the entire section, there will be no doubt that "valid" is defined clearly and quite technically with what conditions must hold true. The current draft is not adhering to these principles. One concrete example of such a technical definition can be found in section 6.4.1:

6.4.1 <https://datatracker.ietf.org/doc/html/rfc7950#section-6.4.1>.  XPath Context

   o  If the XPath expression is defined in a substatement to a data
      node that represents configuration, the accessible tree is the
      data in the datastore where the context node exists.  The root
      node has all top-level configuration data nodes in all modules as
      children.

My conclusion is that the draft text needs to be changed to stay within the bounds of RFC 7950.

> Then the choices become:
> Offline validation of <running> alone is NOT required
> Servers internally validate <running> via validating <intended>
> Offline validation of <running> alone IS required
> Options:
> Clients MUST copy/paste any referenced system configuration into <running>, even though it goes against our objective of avoiding-copy when possible.
> Defer work to be a YANG-next effort.
> Any thoughts on this?

The possibility to reason about and compute configuration changes without involving the server is a key principle of the entire YANG project. By declaring the complete interface in a machine readable way, orchestration clients can do things that were note possible in the past. The effect of the current draft text is to remove that possibility.

With some quite reasonable changes, however, I think the goals of the draft can be accomplished in ways that are compatible with RFC 7950. I have discussed these changes with you, so you know I have in mind. My opinion therefore is that validation without the involvement of the server is required, regardless of the options above. Having said that, I think there are more and better options than option 1 and 2 above.

Best Regards,
/jan

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 23 Nov 2021 11:11:27 +0000

Hi Jan,
You correctly wrote:

Then the choices become:

     *   Offline validation of <running> alone is NOT required
        *   Servers internally validate <running> via validating <intended>
        *
SB> but in fact this is what declared, for my understanding, in RFC 8342, for which “validation” is done on “intended” by the server , as also shown in figure 2 of the RFC. Is it needed to change also RFC?

Thanks
Sergio

From: netmod <[email-masked]> On Behalf Of Jan Lindblad
Sent: Tuesday, November 23, 2021 10:59 AM
To: maqiufang (A) <maqiufang1=[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Must offline-validation of <running> alone be valid?

Qiufang,

6.4.1<https://datatracker.ietf.org/doc/html/rfc7950#section-6.4.1>.  XPath Context

      children.

Then the choices become:

        *   Options:

Best Regards,
/jan

---

From: Jan Lindblad <[email-masked]>
Date: Tue, 23 Nov 2021 18:56:34 +0100

Sergio, Qiufang,

> SB> but in fact this is what declared, for my understanding, in RFC 8342, for which “validation” is done on “intended” by the server , as also shown in figure 2 of the RFC. Is it needed to change a…

According to RFC 8342, *both* running and intended have to be valid at all times. Section 5.1.3 says:

5.1.3 <https://datatracker.ietf.org/doc/html/rfc8342#section-5.1.3>.  The Running Configuration Datastore (<running>)

...
                                                         However,
   <running> MUST always be a valid configuration data tree, as defined
   in Section 8.1 of [RFC7950] <https://datatracker.ietf.org/doc/html/rfc7950#section-8.1>.

Section 8.1 of RFC 7950 was the section I referred to in my previous comment. Section 5.1.4 says:

5.1.4 <https://datatracker.ietf.org/doc/html/rfc8342#section-5.1.4>.  The Intended Configuration Datastore (<intended>)

...
   <intended> is tightly coupled to <running>.  Whenever data is written
   to <running>, the server MUST also immediately update and validate
   <intended>.
 
In my judgement, changing the fundaments of RFC 7950 and 8342 is not going to happen any time soon (for good reason), and there are other (better) options.

> Defer work to be a YANG-next effort.

In order to move forward, I would propose working out some more options in this list. I have suggested a few to the authors that I think are better than the two above, but I will leave it to the authors make the call for what they want to bring up for discussion.

Best Regards,
/jan

---

From: "maqiufang (A)" <[email-masked]>
Date: Wed, 24 Nov 2021 03:41:54 +0000

Hi, Jan,

I do remember that. You mentioned it to me after the interim but I was trying to document the discussion in the interim meeting at that time.
I am very glad to bring your proposal to the WG, if the WG thinks it is the case that offline validation of <running> alone is required.

If my understanding is correct, you suggest there is a new flag(we can call it “with-system-auto”) added to the “edit-config” operation for the clients expected to be lazy.
When this flag is carried, it indicates to the sever to auto-populate referenced but missed system data node into <running> for the operation to be valid.
For the client expected not to be lazy, it’s also the cases that they could explicitly copy/paste system config in <running> without “with-system-auto” flag.

What I am not sure is whether this goes against our goal of “client-control(i.e., a read-back of <running> should contain only what was explicitly set by the clients)”, or it is a compromise that had to be made.

Best Regards,
Qiufang Ma
From: netmod [mailto:[email-masked]] On Behalf Of Jan Lindblad
Sent: Wednesday, November 24, 2021 1:57 AM
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>
Cc: maqiufang (A) <maqiufang1=[email-masked]<mailto:maqiufang1=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] Must offline-validation of <running> alone be valid?

Sergio, Qiufang,

Hi Jan,
You correctly wrote:

Then the choices become:
o    Offline validation of <running> alone is NOT required
§  Servers internally validate <running> via validating <intended>
§
SB> but in fact this is what declared, for my understanding, in RFC 8342, for which “validation” is done on “intended” by the server , as also shown in figure 2 of the RFC. Is it needed to change also RFC?

5.1.3<https://datatracker.ietf.org/doc/html/rfc8342#section-5.1.3>.  The Running Configuration Datastore (<running>)

...

                                                         However,

   in Section 8.1 of [RFC7950]<https://datatracker.ietf.org/doc/html/rfc7950#section-8.1>.

5.1.4<https://datatracker.ietf.org/doc/html/rfc8342#section-5.1.4>.  The Intended Configuration Datastore (<intended>)

...

   <intended>.

o    Offline validation of <running> alone IS required
§  Options:
1.       Clients MUST copy/paste any referenced system configuration into <running>, even though it goes against our objective of avoiding-copy when possible.
2.       Defer work to be a YANG-next effort.

Best Regards,
/jan

---

From: Kent Watsen <[email-masked]>
Date: Mon, 29 Nov 2021 22:08:56 +0000

Hi Jan,

> On Nov 23, 2021, at 12:56 PM, Jan Lindblad <[email-masked]> wrote:
> 
> Sergio, Qiufang,
> 
>> Hi Jan,
>> You correctly wrote:
>>  
>> Then the choices become:

I don’t think the case has been made that *offline* validation of <running> by itself must be valid.  Yes, *online* <running> must be valid, as must <intended>, with the intention of RFC 8342 being that both are validated in one and the same operation by the server  (known to me as an author of RFC 8342).  I understand that implementations may have assumed offline validation of <running> must be valid, I just can’t find the RFC reference that demands it be supported, and without such reference, it falls into an undefined area.  Necessitating offline validation of <running>, if that is what the WG decides, results in solutions for which none seem nice to me, at least I haven’t seen any yet.  Please share any “better options” you have in mind.  

In the meanwhile, can we discuss the issues around a legacy client failing an offline validation?  In this case, a production deployment must have 1) deployed devices that support <system>, 2) deployed at least one client that supports <system>, and 3) decided to let clients start pushing config using <system>.   While in the pre-production testing phase, it would be quickly discovered that all legacy clients need to be updated.  By the time of going to production, the deployment should have all the clients updated, so it seems that only the forgotten (relatively insignificant) clients might have an offline validation of <running> failure.  Is this a fair assessment?

Kent // as a contributor