Subject: [Netconf] New revision of "Discrepancy detection between NMDA datastores" (draft-clemm-netconf-nmda-diff-02)

From: Alexander Clemm <[email-masked]>
Date: Fri, 23 Feb 2018 21:18:51 +0000

Hello Netconf WG,

we posted a new revision of "Discrepancy detection between NMDA datastores" earlier today (https://tools.ietf.org/html/draft-clemm-netconf-nmda-diff-02).  This concerns a straightforward extension to NMDA with a facility that will make troubleshooting and diagnosing error scenarios rooted in inconsistencies between different datastores easier.  The new revision contains some instantiated examples which the previous revisions did not.  At the previous IETF, there seemed to be considerable support for the draft in the room.  We would therefore like to ask for WG adoption.

Thanks
--- Alex (on behalf of coauthors - Yingzhen, Jeff)

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Feb 2018 13:40:22 -0800

Hi,

On Fri, Feb 23, 2018 at 1:18 PM, Alexander Clemm <[email-masked]
> wrote:

> Hello Netconf WG,
>
>
>
> we posted a new revision of “Discrepancy detection between NMDA
> datastores” earlier today (https://tools.ietf.org/html/d
> raft-clemm-netconf-nmda-diff-02).  This concerns a straightforward
> extension to NMDA with a facility that will make troubleshooting and
> diagnosing error scenarios rooted in inconsistencies between different
> datastores easier.  The new revision contains some instantiated examples
> which the previous revisions did not.  At the previous IETF, there seemed
> to be considerable support for the draft in the room.  We would therefore
> like to ask for WG adoption.
>
>
>

This draft fixes 1 shortcoming of NMDA, so the problem should be addressed.

Using your example:
https://tools.ietf.org/html/draft-clemm-netconf-nmda-diff-02#section-6

The source is <intended> and the target is <operational>.
What does that mean for a compare?
Seems like the right terminology for copy-config, but not compare.

       <differences>
         <yang-patch>
           <patch-id>p101</patch-id>
           <edit>
             <edit-id>1</edit-id>
             <operation>replace</operation>
             <target>
               /ospf:ospf/ospf:instance[ospf:af='1']/ospf:areas/
                 ospf:area[ospf:area-id='1']/ospf:default-cost
             </target>
             <value>
               <default-cost>128</default-cost>
             </value>
           </edit>
         </yang-patch>
       </differences>

The differences show a replace operation.
It does not show the value in the source that was replaced.
What if the RPC augmented the "edit" list with an anydata node named
<old-value>

             <old-value>
               <default-cost>100</default-cost>
             </old-value>

I assume if the source did not exist, then a "create" operation is returned
instead
(and no <old-value> returned)

Since NMDA allows a server to omit modules from <operational>, would the
diff result be full of "delete" operations for the missing nodes in
<operational>?

The "dampening" behavior is not clear and seems very expensive to implement
(tracking stability duration for individual data nodes).  IMO it should be
removed.

Thanks
>
> --- Alex (on behalf of coauthors – Yingzhen, Jeff)
>
>
Andy

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

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 23 Feb 2018 22:50:49 +0000

Hi Andy,

thank you for your response!  Please see inline, <AC>

--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Friday, February 23, 2018 1:40 PM
To: Alexander Clemm <[email-masked]>
Cc: [email-masked]; Yingzhen Qu <[email-masked]>; [email-masked]
Subject: Re: [Netconf] New revision of "Discrepancy detection between NMDA datastores" (draft-clemm-netconf-nmda-diff-02)

Hi,

On Fri, Feb 23, 2018 at 1:18 PM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:
Hello Netconf WG,

we posted a new revision of “Discrepancy detection between NMDA datastores” earlier today (https://tools.ietf.org/html/draft-clemm-netconf-nmda-diff-02).  This concerns a straightforward extension to NMDA with a facility that will make troubleshooting and diagnosing error scenarios rooted in inconsistencies between different datastores easier.  The new revision contains some instantiated examples which the previous revisions did not.  At the previous IETF, there seemed to be considerable support for the draft in the room.  We would therefore like to ask for WG adoption.

<AC> Thanks! </AC>

Using your example:

<AC>I am not sure I understand your question – you would not copy-config directly into operational, also what if you want to check for differences before you decide to do a “copy-config” (to “blanket” any differences that may have existed)? </AC>

       <differences>

         <yang-patch>

           <edit>

             <edit-id>1</edit-id>

             <target>

             </target>

             <value>

             </value>

           </edit>

         </yang-patch>

       </differences>

The differences show a replace operation.
It does not show the value in the source that was replaced.
What if the RPC augmented the "edit" list with an anydata node named <old-value>

             <old-value>

             </old-value>

I assume if the source did not exist, then a "create" operation is returned instead
(and no <old-value> returned)

<AC> Sure, this is something that can  certainly be accommodated.  Our current model was to show the difference in terms how you can go from one to the other,  another model is to show the source value specifically in case of update.  (We should call it <source-value>, not <old-value>).  And, if you can help us with regards to how best work this in conjunction with yang-patch, that will certainly be appreciated!
</AC>

Since NMDA allows a server to omit modules from <operational>, would the
diff result be full of "delete" operations for the missing nodes in <operational>?

<AC> The short answer is “yes”.  Fundamentally this is just a compare operation.  Now, that said, it is certainly conceivable to make the compare operation smarter.  One proposal that we discussed, but eventually decided against to keep things simpler, was with regards to <operational> to only include data nodes in the comparison whose origin is the datastore the <operational> is being compared with.  If needed, this could certainly be made an option as it seems fairly straightforward.  At the same time, in some cases it may be interesting to find discrepancies when the origin is something different than was expected (e.g. a data node whose origin in <operational> shows as “system”, although the same data node is also in <intended>).
</AC>

The "dampening" behavior is not clear and seems very expensive to implement
(tracking stability duration for individual data nodes).  IMO it should be removed.

<AC> Because it can be expensive to implement it is conditional on an extra feature (“cmp-dampening”).  At the same time, this seems to be a feature that would be very useful to client applications, to not be inundated with discprepancies that are only very short-lived in nature and resolve themselves.  For this reason we chose to include it.  Again, as a feature, implementation would be optional.
</AC>

Thanks

Andy

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 24 Feb 2018 15:57:20 +0100

Hi,

I do not like the term "discrepancy detection" or "comparing
discrepancies"; I think this is really just a datastore compare
operation. The abstract should simply start with:

  This document defines an RPC operation to compare datastores.

Avoid talking about capability since capabilities have a special
meaning. The 'set of RPCs' seems to have size one (and we usually
write NETCONF and RESTCONF).

You may have to think what you include in the comparion, in particular
when we consider <operational>. If you compare <operational> with
<intended>, you likely want to skip over all "config false" nodes and
you may want to skip over nodes that have a "non-suitable" origin.

I share Andy's concerns about cmp-dampening - perhaps it is best to
leave this for vendor extensions for a first version of this. (It is
also not exactly clear how this would work, what about stuff that is
changing during the dampening period?)

Some of the references do not seem to be needed (did not find
citations for them).

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