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

["Xufeng Liu" <[e-mail]>]

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

> 
> 
> /martin
> 
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs