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

[Andy Bierman <[e-mail]>]

On Thu, Feb 16, 2017 at 1:19 PM, Martin Bjorklund <[e-mail]> wrote:

> "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.
>
>
+1

There are billions of combinations of letters than can be used as YANG
identifiers.
The letters "get-config" are already used.  Pick a different combination.



>
> /martin
>


Andy


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