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

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

Hi Sue,

I agree that the revised data stores solutions is the long term solution,
but it may take a year to complete because it covers a much broader scope.
Are we ok with delaying all these models for another year? This could be the
decision of the Chairs and ADs. Also, this approach seems to be a sub-set of
the long term solution, and they are compatible. If the details can be
worked out, it would be good to have such an interim solution immediately,
which does not need to solve all the problems, but hopefully can migrate to
the long term solution smoothly.

Thanks,
- Xufeng

> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Thursday, February 16, 2017 2:53 PM
> To: 'Xufeng Liu' <[e-mail]>; 'Martin Bjorklund'
<mbj@tail-
> f.com>; [e-mail]
> Cc: [e-mail]
> Subject: RE: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> 
> Xufeng:
> 
> I suspect 2 rpcs will be needed, but Martin and Kent are the experts.   Do
> you think trying to accelerate the revised data stores solutions is a
better way to
> go?
> 
> Sue
> 
> -----Original Message-----
> From: i2rs [mailto:[e-mail]] On Behalf Of Xufeng Liu
> Sent: Thursday, February 16, 2017 2:48 PM
> To: 'Susan Hares'; 'Martin Bjorklund'; [e-mail]
> Cc: [e-mail]
> Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> 
> Hi Sue,
> 
> > -----Original Message-----
> > From: Susan Hares [mailto:[e-mail]]
> > Sent: Thursday, February 16, 2017 2:02 PM
> > To: 'Xufeng Liu' <[e-mail]>; 'Martin Bjorklund'
> <mbj@tail-
> > f.com>; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [i2rs] modeling options for
> > draft-ietf-i2rs-yang-network-topo
> >
> > To Xufeng:
> >
> > Clarifying question - Are you asking about I2RS topology as a generic
> > yang model for any configuration or are you asking about I2RS topology
> > model as
> an
> > ephemeral topology model.
> 
> [Xufeng] I was talking about I2RS topology as a generic yang model for any
> configuration, but I think that the same solution can be applied to
ephemeral
> case, though a separate rpc might be needed.
> 
> Thanks,
> - Xufeng
> 
> >
> > To Martin:
> > Clarifying questions:
> >
> > 1)  Is your rpc suggest target toward the I2RS topology model as a
> > generic topology model or an I2RS ephemeral state model or both?
> >
> > 2) Could we define rpcs now that operate as Alex desired for generic
> topology
> > models that could be replaced by more generic mechanisms later?
> > For example, the I2RS RIB has defined rpcs for all major functions
> (add/delete rib,
> > add/delete route, add/delete nexhop) plus notifications for changes.
> > Is
> this the
> > best approach here?
> >
> > Sue
> >
> > -----Original Message-----
> > From: i2rs [mailto:[e-mail]] On Behalf Of Xufeng Liu
> > Sent: Thursday, February 16, 2017 10:39 AM
> > To: 'Martin Bjorklund'; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [i2rs] modeling options for
> > draft-ietf-i2rs-yang-network-topo
> >
> >
> >
> > > -----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
> >
> > _______________________________________________
> > i2rs mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i2rs
> 
> 
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs