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

[Kent Watsen <[e-mail]>]

[moving yang-doctors to BCC]


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

I'm referring to how the description statement explains that
the server may look to operational state in order to resolve
the leafref, which is to result in behavior similar to 
pre-configuration in RFC 7223.



>>   b) complex server implementation (to handle require-instance false)
>
>Can you elaborate on this one?

This is primarily a reflection of the CON listed above, in that
it seems that a server would need to have special handling for 
when dependencies transition from being present to not-present
and vice versa, much like the code to handle when a physical
card is plugged in or removed.

Note: I should've listed this as a CON for OPTION 2 as well.



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

There are two primary differences:

1) It doesn't break legacy clients, because it requires the client to
   explicitly pass a 'with-server-provided' flag in the <get-config>
   request in order to get back the extended response.  Likewise, it
   doesn't break backup/restore workflows, as the server can discard
   any 'server-provided' nodes passed in an <edit-config> operation.
   Lastly, it doesn't break <lock>/<unlock>, as there is no comingling
   of opstate data in the 'running' datastore.

2) It doesn't say anything about how the opstate data is stored on the
   server.  The opstate data is not modeled at all.  This approach 
   only defines a presentation-layer format for how opstate data can
   be returned via an RPC.  The server is free to persist the opstate
   data anyway it wants, perhaps in an internal datastore called 
   'operational-state' or in an uber-datastore with the opstate data
   flagged with a datastore='oper-state' attribute.  Regardless, it's
   an implementation detail, and the conceptual datastore model is
   preserved.



> /martin

Kent




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