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?
Sue -----Original Message----- From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin Bjorklund Sent: Thursday, March 16, 2017 4:18 AM To: kwat...@juniper.net Cc: i2rs@ietf.org; xufeng.liu.i...@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 <kwat...@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 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
