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

["Susan Hares" <[e-mail]>]

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