Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

[Martin Bjorklund <[e-mail]>]

Hi,

Kent Watsen <[e-mail]> wrote:
> Hi All,
> 
> It's been quiet on the list as a small group of us (Alex, Xufeng,
> Pavan, and myself) went offline to discuss for a bit before bringing
> back to the group, which I'm doing now.
> 
> Regarding resolving the modeling the issue, we went through nearly a
> dozen ideas that we've narrowed down to two.  We discussed the
> pros/cons, but since we each emphasize different values, we were
> unable to reach a consensus amongst ourselves.  We're hoping that
> bringing the discussion here will bring more perspectives and resolve
> this issue.
> 
> 
> OPTION 1: separate /foo and /foo-state trees
> --------------------------------------------
> 
> This option was/is described here:
> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> 
> PROS:
>   a) does NOT break legacy clients (how we got here)
>   b) consistent with convention used in many IETF modules
>   c) able to show if/how opstate may differ from configured values
> 
> CONS:
>   a) questionably valid YANG leafref usage

What does this mean?

>   b) complex server implementation (to handle require-instance false)

Can you elaborate on this one?

>   c) eventually the module would need to migrate to the long-term 
>      solution, which would result in needing to also rewrite all
>      modules that have augmented it (e.g., ietf-te-topology).
>   d) leafref path expressions really only work for configuration data,
>      though a clever server could have a special ability to peak at
>      the opstate values when doing validations.  Of course, with 
>      require-instance is false, the value of leafref based validation
>      checking is negated anyway, even for config true nodes, so this
>      may not matter much.
> 
> 
> 
> OPTION 2: explicit client-option to also return tagged opstate data
> -------------------------------------------------------------------
> 
> This option takes a couple forms.  The first is module-specific and
> the second is generic.  In both cases, the idea is modeled after the
> with-defaults solution (RFC6243), wherein the client passes a special
> flag into <get-config> causing the server to also return opstate data,
> having a special metadata flag set, intermingled with the
> configuration
> data.
> 
> 
> 2A: Module-specific version
> 
>    module foo {
>       import ietf-netconf { prefix nc; }
>       import ietf-yang-metadata { prefix md; }
>       md:annotation server-provided {
>          type boolean;
>       }
>       container nodes {
>          config true;
>          list node {
>             key "name";
>             leaf name { type string; }
>             leaf dependency {
>                type leafref {
>                  path "../node/name"
>                  require-instance false;
>                }
>             }
>          }
>       }
>       augment /nc:get-config/nc:input {
>          leaf with-server-provided {
>             type boolean;
>          }
>       }
>    }

I don't think this solution is substantially different from the
solution in draft-ietf-i2rs-yang-network-topo-10.  You have just moved
a config false leaf to a meta-data annotation.  This solution suffers
from the same problems as the solution in
draft-ietf-i2rs-yang-network-topo-10.



/martin




> 
> For instance:
> 
>   <get-config>
>     <source>
>       <running/>
>     </source>
>     <with-server-provided/>
>    </get-config>
> 
>    <data>
>      <nodes>
>        <node>
>          <name>overlay-node</name>
>          <dependency>underlay-node</dependency>
>        </node>
>        <node foo:server-provided='true'>
>          <name>underlay-node</name>
>        </node>
>      </nodes>
>    </data>
> 
> PROS:
>   a) does NOT break legacy clients (how we got here)
>   b) having all data in one merged tree is simpler to process 
>      than two separate queries.
>   c) module doesn't have to be rewritten for revised-datastores;
>      the 'with-server-provided' switch would just not be passed
>      by new opstate-aware clients.
> 
> CONS:
>   a) inconsistent with convention used in many IETF modules
>   b) unclear how to model 'with-server-provided' for RESTCONF
>      (just use a description statement to define a query param?)
>   c) unable to return the opstate value for any configured node
>      (is it needed here?)
>   d) requires server to support metadata, which is a relatively
>      new concept and maybe not well supported by servers.
>   e) only changes presentation-layer (doesn't change the fact 
>      that 'server-provided' data is not configuration), thus the
>      leafref path expressions still don't work quite the way as
>      desired, though a clever server could have a special ability
>      to peak at the opstate values when doing validations. Of 
>      course, with require-instance is false, the value of leafref
>      based validation checking is negated anyway, even for config
>      true nodes, so this may not matter much.
> 
> 
> 
> 
> 2B: Generic version
> 
> The generic version is much the same, but rather than letting the
> solution be limited to this one module, the idea is to generalize
> it so it could be a server-level feature.  Having a generic RPC to
> return data from more than one DS at a time was something that was
> discussed ~1.5 years ago when we were kicking off the opstate effort.
> 
> The PROS and CONS are similar, but there are additional CONS in the
> generic case.  The main ones being 1) how to simultaneously return 
> both the config and opstate values for a node (split at the leaves)
> and 2) how to handle some YANG statements such as presence containers
> and choice nodes.  For this reason, (2B) is NOT considered a viable
> solution and is only here so that it's clear that it was discussed.
> 
> 
> 
> If there are any other options people want to suggest, please do so
> now!
> 
> Thanks,
> Kent
> 
> 
> 
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>