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

"Susan Hares" <shares@ndzh.com> wrote:
> Martin: 
> 
> Thank you for reviewing this option.  In your opinion, how long do you think
> the generic solution based on the draft-ietf-netmod-revised-datastores will
> take to complete? 

>From the authors' pow, we believe we have addressed all technical
issues.  The document needs to be split into protocol documents and a
pure architecture document; this will happen after Chicago, if the WGs
(NETCONF and NETMOD) agree.  Of course, in the end the fate of the
document is up to the WG to decide about...


/martin


> 
> Sue 
> 
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund
> Sent: Thursday, March 16, 2017 4:18 AM
> To: kwatsen@juniper.net
> Cc: i2rs@ietf.org; xufeng.liu.ietf@gmail.com
> Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> 
> Hi,
> 
> So this new option 3 tries to fast-track what's being done in
> draft-ietf-netmod-revised-datastores.  It has to solve many of the issues
> that we face in that draft.  It is not clear to me that this will produce a
> result that (i) is completed much faster than that draft and (ii) is
> guaranteed to be compatible with the solution in that draft.
> 
> So I still think that option 1 is the best way forward (unless this draft
> can wait for the generic solution in draft-ietf-netmod-revised-datastores).
> 
> 
> /martin
> 
> 
> Kent Watsen <kwatsen@juniper.net> wrote:
> > Hi Martin,
> > 
> > Speaking with the authors offline late last week, this discussion 
> > regarding OPTION-2 came up, and I mentioned again my concerns for CON 
> > 'c':
> > 
> >   c) unable to return the opstate value for any configured node
> >  
> > ...to which the Xufeng suggested we take your idea to heart.
> > Specifically, rather than augment <get-config>, let's look-ahead and 
> > use the opstate <get-data> RPC (including the 'origin' attribute) now.  
> > This way, <get-config> would return the configured value, while 
> > <get-data> could return the applied value, as well as the system 
> > generated/learned topology.  So, as in previous fashion, I formally 
> > submit OPTION 3:
> > 
> > 
> > 
> > OPTION 3: use new RPC <get-topo-data>, which is just like <get-data>
> > --------------------------------------------------------------------
> > 
> > This option defines a new RPC called <get-topo-data> that is fashioned 
> > directly after the <get-data> RPC from the revised-datastores draft.
> > The RPC is renamed for fear of conflicting with any possible future 
> > changes that may occur to the planned <get-data> RPC.  The 
> > <get-topo-data> RPC would take an optional 'with-origin-data' selector to
> return the 'origin' attribute.
> > 
> > PROS:
> >   a) does NOT break legacy clients (how we got here).
> >   b) ability to return the opstate value for any configured node.
> >   c) minimal rewrite of the module for revised-datastores solution.
> > 
> > CONS:
> >   a) seems like a shady thing for an IETF module to do.
> >   b) would need to resolve other issues (e.g., how to support with
> >      RESTCONF), which makes the draft quite a bit more than just
> >      a module draft.
> >   c) requires server to support metadata, which is a relatively
> >      new concept and maybe not well supported by servers.
> > 
> > 
> > Thanks,
> > Kent
> > 
> > 
> > 
> > -------ORIGINAL MESSAGE-------
> > >>>> 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,
> > 
> > Going back your earlier "better to define a new rpc" comment, I fail 
> > to see how this proposal is significantly different than RFC 6243.
> > 
> > If not this, then the new RPC would be something like <get-config-ex> 
> > more than the planned <get-data>, as the goal is to return 'running'
> > + "some opstate" (not just opstate).
> > 
> > Still, in looking the the pros/cons, Option 1 appears stronger - only 
> > the authors don't like the idea of having to rewrite their models 
> > later...
> > 
> > Kent
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > i2rs mailing list
> > i2rs@ietf.org
> > https://www.ietf.org/mailman/listinfo/i2rs
> > 
> > 
> 
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>