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

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

Martin: 

As always - you provide just the right information.  I2RS will meet after
the NETCONF meeting and the 1st NETMOD meeting, so we'll be able to adapt to
WGs actions.   Thank your (you and your co-authors) excellent work on
draft-ietf-netmod-revised-datastores. 

Sue 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Martin Bjorklund
Sent: Thursday, March 16, 2017 8:52 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

"Susan Hares" <[e-mail]> 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:[e-mail]] On Behalf Of Martin 
> Bjorklund
> Sent: Thursday, March 16, 2017 4:18 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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 <[e-mail]> 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
> > [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