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

[Martin Bjorklund <[e-mail]>]

"Xufeng Liu" <[e-mail]> wrote:
> 
> 
> > -----Original Message-----
> > From: i2rs [mailto:[e-mail]] On Behalf Of Martin Bjorklund
> > Sent: Tuesday, February 14, 2017 11:41 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> > 
> > Kent Watsen <[e-mail]> wrote:
> > >
> > >
> > > [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.
> > 
> > Ok, I didn't pay close attention to the proposal in the quoted email.
> > 
> > I would design this a bit differently.  The config true leaf "dependency"
> should
> > have a leafref to the config false node name, with require-instance false.
> The
> > description should explain that the configuration item will be used by the
> server
> > if all dependencies exist.  When the configuration item is used, it shows
> up in the
> > config false list.
> > 
> > This way, the leafref usage is valid and straight forward.
> > 
> > > >>   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.
> > 
> > Yes, but I think this is inherent to the problem at hand.  Even with the
> config true
> > solution defined in the current draft, it is not clear how things that
> were created
> > by the server would be deleted (if there were references to them).
> > 
> > > 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
> > 
> > The solution in the draft doesn't break legacy clients either - there's a
> config
> > false leaf among the config true.  No problem.
> > 
> > >    , 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.
> > 
> > Huh?  This goes against the defined behavior of 6241 + 7950.  This is the
> main
> > problem with the solution in the current draft.
> > 
> > If a client sends a <get-config> for data in running, the server cannot
> send back
> > data that is not in running.
> > 
> > >    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.
> > 
> > You are essentially defining a new operation, but do it by modifying the
> > semantics of an existing one.  I don't think this is a good idea; it is
> better to
> > define a new rpc.
> 
> [Xufeng] Is using a new rpc is acceptable? If so, this could be a viable
> option.

The draft-ietf-netmod-revised-datastores proposes a new rpc (maybe
<get-data>) to return data from the new operational-state datastore.
This is IMO better than adding opstate nodes to the reply to a
<get-config> request.


/martin