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

[Martin Bjorklund <[e-mail]>]

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
> 
>